> I thought of this. I noticed that the NKConnection Kit adds methods to 
> Morph.  Frankly, doing this in my own case bothers me -- a lot.  It 
> certainly would work for *me* -- for my own "private" image.  But what if 
> *everyone* did this?  Are you really saying that it's OK for everyone who 
> has something they want to do in Squeak to add methods to Morph?  If 
> everyone does this, there will be method explosion in class Morph that will 
> get out of hand in no time flat.  Or else there will be a gazillion 
> incompatible images, and no one will be able to know what "the real class 
> Morph" does.  


I'll pipe up with the contrary view.  It's not a big deal, up until
people start trying to define selectors with the *same* name.  I've
found it convenient both technically and mentally to add methods like
#fribbleIfYouWanna.  The implementation in Morph does nothing (it
doesn't wanna), and implementations in my classes will fribble as
appropriate.  Technically, this is okay because other people's code
won't be using these selectors, and thus they will see the same old
Morphic behavior they are used to.  Philisophically, Morph is simply
learning to do something new; it still knows everything it knew before,
and the two tasks don't interfere with each other.

In general, using classes as a basis for modules seems to lead to
complication.  Just because other languages do it, doesn't mean they
were right.

Now, there is certainly a design question here: could you really be
talking to any arbitrary morph?  It seems better to avoid such situation
if you can.  Nevertheless, sometimes you you are stuck, e.g. you might
be dealing with drag-and-drop.


Finally, you mention "the real Morph".  There is an essence of being a
Morph, and it certainly would be nice if people reading the code can
focus on that essence to begin with.  Modules would solve this problem
nicely: the Morphic module would contain Morph's essential methods, and
Morph's other methods would be scattered among the modules they support.


-Lex