At 11:04 PM 1/20/2002, you wrote:
>--On Sunday, January 20, 2002 9:54 PM -0500 "Andrew C. Greenberg" 
><werdna at mucow.com> wrote:
>
>>There are zillions of ways to do what you describe, the simplest,  far
>>from the most elegant, but far more elegant than this code, would be to
>>simply define a default method in Morph (or the GCD of the class
>>hierarchy in which you will be working), that does something reasonable.
>
>Well ...
>
>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.  Or else there will be a horrendous political process to cull 
>all of the add-on methods to Morph for which ones to "bless" in the 
>official image.

Congratulations on the hat trick, Jim. :)   Exactly right.

In general, a way to avoid this would be to separate your special behavior 
and state into a model class, which your morphs would have hold of.  Then 
using one of several techniques, and most probably a mixture of techniques, 
have the model respond appropriately to the interaction.  You can register 
event actions or forward view callbacks to your model.  You can also have 
your Views respond to events that occur elsewhere in the system.  Take a 
look at the class Model and look at how some of it's subclasses work.

>I really like the idea that my classes can be filed in and just work -- 
>there's no messing with anything outside my own class definitions, which 
>just use garden variety subclassing.  It seems to me that adding methods 
>to Morph should be for functionality that is so useful, a very significant 
>percentage of Squeakers are likely to be able to use it. As opposed to 
>adding "application level" functionality for *my* quite -- uh shall I say 
>"individual" -- set of behaviors.
>
>There really is no less obtrusive class than Morph to which my methods can 
>be added if I'm not going to test a morph first to see if it understands 
>my methods.  I need to send them to the *owner* of a morph, and I don't 
>want to make any assumptions at all about what submorphs that owner might 
>have that aren't "my classes".

For this situation, you may want your submorphs to register for events from 
your model, which is not the owner morph (this is event registration in the 
opposite direction  Morph -> Model).   Then, instead of sending to the 
owner Morph, you would tell your model object to do xyz.  It would, in 
turn, notify your registered sibling morphs that that particular event just 
occured.  there are several ways of doing this, including (#addDependent:, 
#changed:, #update:), (#when:send:to:, #trigger:with:, #removeActions...), 
and (#on:send:to:, which is more of the Morphic specific multicast event 
system), or (yuck) your model could hold onto all the submorphs that you 
care about talking to, and send direct messages, although this may make 
sense if you have a finite set of unique submorphs each providing unique 
services.  This somewhat breaks the composability of Morphic however.

In using event registrations, make sure you are careful about deregistering 
at the right time.   Otherwise your objects become the undead.

Rob