<br><br><div class="gmail_quote">On Tue, Jun 30, 2009 at 4:53 PM, Cameron Sanders <span dir="ltr"><<a href="mailto:csanders.personal@functional-analyst.com">csanders.personal@functional-analyst.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
On Jun 30, 2009, at 12:22 AM, Michael van der Gulik wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Back to the question of adding behavior to classes that you don't own. VisualWorks has a means to extend a class in a different package ... as I recall. As I recall, squeak has no such capability, right?<br>
<br>
<br>
Squeak certainly has that capability, but I would discourage you from using it.<br>
</blockquote>
<br></div>
Why?
</blockquote></div><br><br>It's a gut feeling thing rather than any serious good coding practise.<br><br>Often if you feel the need to put code for your package in another package, then that other package was somehow deficient and your modifications should be made to that other package "properly".<br>
<br>If your package modified another package such that it gains knowledge of other class's internal behaviour, you're breaking encapsulation and leaving your code prone to breakage when that other package changes.<br>
<br>Collisions can occur if two packages try to modify the same method on a third package.<br><br>It spreads your code around. I like to keep my code in one place and I've personally got a tendency to write slightly less elegant code which is "right here" in preference to modifying external classes.<br clear="all">
<br>Gulik.<br><br>-- <br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/</a><br>