On Monday, January 21, 2002, at 05:24  PM, Noel J. Bergman 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.
>
> Personally, I cringe when I read something like that.  As a general 
> rule for
> managing a public class library, I would consider it poor practice to 
> add
> personal behaviors to public classes.

Reasonable minds may differ.  Others consider it exceptionally poor 
practice to use class-testing alternative constructs.  Purists find 
fault even with nil-testing alternative constructs.

Which is worse depends, largely, upon the nature of the application 
itself, and the proposed solution.  If the application is, itself, 
fundamentally a tool for maninpulating ALL classes, it may very well be 
beneficial -- indeed best, to provide methods for the GCD class in the 
manipulated hierarchy.  Care must be taken, of course, to avoid certain 
kinds of bloat, and there ought to be a REAL GOOD REASON to approach the 
problem this way.  However, circumstances exist that reasonably 
constitute such RGR's, and --more important-- the beauty, reusability, 
maintainability and elegance of the corresponding code once this is done 
makes a compelling case in such instances.

> The solution is pre-qualified as being far from elegant, but why not 
> suggest
> A Better Way, as the original question desired?

I thought I offered one.  As between the two pieces of code, no question 
which is the better way.  Using a more direct form of querying the 
entity -- same result.  I also recommended that he explain the overall 
circumstances so we could give meaningful advice.

> Is this really considered
> good programming practice in Smalltalk?  If not, then why start a 
> Smalltalk
> 101 programmer down such a poor practice in the first place?

I haven't been beating my wife lately.  Obviously, I didn't agree with 
your antecedent proposition, hence I disagree with the conclusion.  
Suggest various textbooks that address these smells in greater detail.  
I'm particularly fond of "Refactoring."