On Sunday, January 20, 2002, at 11:04  PM, Jim Rosenberg 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?

It *is* OK, but it is rarely appropriate.  What dictates the answer to 
that question is the actual problem you are trying to solve.

> If everyone does this, there will be method explosion in class Morph 
> that will get out of hand in no time flat.

Hence we have subclasses, in which such methods are often added, which 
are often more appropriate vehicles for solution.  There are a host of 
other techniques available as well.

> 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.  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.

I understand how this must seem or feel to you, but you asked me how I 
felt, and why.  You are free, of course, to reject my remarks, and 
follow your own stars.  My suggest is to look at many different views.  
But let's remember who was starting with Smalltalk 101.

The concerns you identified are relevant, but not entirely dispositive.  
They are traditionally addressed in different ways -- the subject of 
modules and modularity raised in other threads are a piece of that -- 
proper tools make these concerns less of a practical issue.  Absent such 
tools, and even with them, the concerns you are valid, and alternative 
solutions should be sought to avoid these issues in many cases.  Where 
we differ, is how much to weigh them in the context of the world you 
have entered.

But there are serious problems with your proposed alternative as well.  
As between the two, the answers are clear, at least to me.  Alternative 
constructs are smells that defy or limit OO benefits -- PRECISELY for 
the reasons you stated -- repetitive constructs rampant throughout your 
code.  They make reusable code non-reusable and make maintaining code 
quite difficult as a practical matter.

In practice, and in most situations, there are often other 
alternatives.  Usually many such alternatives are available, and 
compromises between them that reasonably addresses many issues.

> 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".

Really?  What, EXACTLY, are you trying to do that justifies such 
extravagant statements?  Perhaps, as I noted in my earlier response, you 
are asking the wrong questions at the outset.  Only when we look at the 
real problem can these concerns be meaningfully weighed.  I note that it 
is rarely necessary for a well-defined and well-designed application to 
repeatedly and awkardly "test ... to see if [an object] understands my 
methods," and certainly not merely by the name of the user-domain 
methods.

As I noted, rather than assuming the validiity of the question to 
resolving your design problem -- perhaps we ought to analyze the design 
itself.  What problem are you solving that requires this design -- what 
alternatives are available.

But I would suggest reading some of the excellent books around on object 
programming.  The paradigms and methodologies ARE different, and the 
concerns ARE different; fundamentally different.  But it takes a while 
to see why this is so.