On Jun 30, 2009, at 12:22 AM, Michael van der Gulik wrote:

> 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?
>
>
> Squeak certainly has that capability, but I would discourage you  
> from using it.

Why?

> Changing the implementation of doesNotUnderstand: is a code smell.  
> You're starting to play with voodoo and you need a *very* good  
> reason to do it. Otherwise you'll have made yourself a very  
> difficult application to debug.

I have done it a fair amount for mapping symbols in broker objects...  
so that symbols may look like unary messages. It is slower than simply  
invoking some keyword message directly, but it really gives the right  
feel for some objects. e.g. ResultsSet.

And you are right, it will likely lead to a debugging nightmare. In  
some cases I have built symbol stacks to aid in debugging -- i'm  
tired, this is hurried.... my apologies if it is unclear. (Besides, I  
doubt you care...)

> In my opinion (which doubtless isn't shared by everyone here), base  
> classes such as Object should not have a lot of >>isXXX methods.  
> >>isBoolean and >>isString are okay (although I never use them), but  
> >>isMorph or >>isColor or anything not related to the Kernel classes  
> are pollution.

I agree with you here too.

> If you're using an >>isXXX method, then your code probably needs  
> refactoring. It means you're implementing class specific behaviour  
> using conditional >>ifTrue: blocks. Typically, your code will be  
> working with subclasses of a specific class, and you'd invoke  
> polymorphic methods to get class specific behaviour rather than  
> using conditional blocks such as >>ifTrue:, >>ifFalse: etc.

Some specialized containers may wish to process some things  
differently than others. But I agree that OO code should not  
frequently be branching on type-tests.

Cheers,
Cam