[squeak-dev] Object>>is:

Stéphane Rollandin lecteur at zogotounga.net
Fri Feb 11 21:44:59 UTC 2011


>  I think #is: is a terrible idea

A possible solution is to name it #isA: and limit its semantics to 
inheritance testing only. We discussed this at length one year ago in 
that thread:

http://forum.world.st/Object-gt-gt-is-was-Re-PackageDependencyTest-td1578541.html
(and following pages)



The reason I thought (and still think) Object>>#is: is a bad design for 
protocol implementation can be summarized by the following citations of 
mine (see the thread for more context):

----

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:

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.

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.

----

#is: becomes an attractor, a fixed point for all protocols, dispatched
on all classes and having to support all packages. it's another form of
the God class: it's the God method for protocols. this is not OOP as I
understand (and practice) it.

----



I was answered by proponents of Object>>#is: that my points were moot 
because extension methods were evil and I was doing monkey patching. So 
in the end we talked about what is good practice in that matter, and 
disagreed :)



Stef



More information about the Squeak-dev mailing list