Stéphane Rollandin wrote:
>> I really fail to see how #is: is complex and messy. Really.
>
> well for one thing all #is:-type of attributes have to be centralized 
> in one place, the #is: method.

That's actually the good part. You have all the answers to is: aProtocol 
in one place. Thats good, not messy.

> a Morph that isMorph, isBeautiful and isWhatMyUncleLikes has to 
> provide the three answers to very different questions in the same 
> place. Now if another package needs to know if a Morph isMyCupOfTea, 
> it must override aMorph>>#is:

I'd strongly suggest doing some new morph classes that can be your cup 
of tea. And just implement #is: in those. I that way, Morph does not 
need to know at all what a cup of tea is.

> so #is: can not actually safely belong to a single package. while 
> #isWhatMyUncleLikes will only be in my package MyUncle, except if 
> someone else has the same kind of weird ideas about protocol names.

Same as before. The only classes that should ever know about the concept 
of what your uncle likes are those in package MyUncle. The current 
implementation in Morph is perfectly good for that. If used properly, 
this actually decreases the need for overrides. No method in Morph, in 
any package, should know about your uncle or your cup of tea.

> plus, looking for the senders of #isBeautiful immediately gives me all 
> classes responding to the protocol. with the #is: idea, all protocols 
> are mangled in one: you have to look at all #is: implementations, in 
> all objects (!) to see where you protocol went. if that's not messy, 
> call me Joséphine.

I guess you meant 'implementors' and not 'senders'. Anyway, with #is: 
you just ask for senders of #Beautiful and you get an exact answer, 
without any spurious classes answering false.

Cheers,
Juan Vuletich

> regards,
>
> Stef
>