[squeak-dev] Re: Object>>#is:? (was: Re: PackageDependencyTest)
siguctua at gmail.com
Thu Mar 4 21:04:17 UTC 2010
2010/3/4 Stéphane Rollandin <lecteur at zogotounga.net>:
>> 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.
> 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:
why Morph should ever care about answering to isBeatiful or isWhatMyUncleLikes ?
isMorph is enough.
If your object supports multiple aspects , like
then i'd expect to have a single class for every single aspect.
> 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.
ah yeah! And to achieve this, you need to patch an Object class by
But Object really does not belongs to your package.
> 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.
No. Things remain same, if you will use #is: in a way, how Juan using it
^ aSymbol == #myUniqueAspect ifFalse: [ super is: aSymbol ]
if you browse all senders of #myUniqueAspect, you will easily find this method.
Btw, i'm also think that adding #isKindOf: to base class is an overkill.
Igor Stasenko AKA sig.
More information about the Squeak-dev