[squeak-dev] Re: Object>>#is:? (was: Re: PackageDependencyTest)

Igor Stasenko siguctua at gmail.com
Thu Mar 4 20:52:18 UTC 2010

2010/3/4 Stéphane Rollandin <lecteur at zogotounga.net>:
>> A subclass inherits all aspects of parent class.
>> Think how many things you will need to override, if you would want to
>> subclass from a Number but don't behave like number.
> If #is: implementation has to reflect a class hierarchy, then I don't see
> how it can be any better than #isKindOf: and #isMemberOf:
>> Obviously, in your example you showing how to not abuse inheritance.
> My example is based on real, actual code. I use quite a feww isXXX methods
> to ask objects about a property or a protocol they may or not have. It works
> fine and allows me to control fine discriminations along the inheritance.

Then, please , give me a concrete example, where you will have 3 classes,
answering to isXXX message differently:

base (false) -> parent(true) -> subclass(false).

> That's not abusing, that's designing.

No it is abuse. By taking your example as a guide, then what stops me
from creating Morph subclass, which
answers false to isMorph message.  Do you still see nothing wrong with it?

>> And its nothing to do with #is: method :)
> Yes, because #isXXX messages are quite special methods: they mostly return
> mere ^true or ^false. So we are talking in this specific case about
> replacing a simple modular, orthogonal set of clear implementations with
> something much more complex and messy.

hmm.. i don't see anything messy here. It removes a bloat of #isXXXX
methods in many places.
Usually, when you introducing a new aspect in your class, you just
override the #is: method with following:

is: aSymbol
  ^ aSymbol == #myAspect ifFalse: [ super is: aSymbol ].

While if you use isXXX method, obviously you will need to add it to
base class (most of the times - Object) and then override it in your

>>> I have to be aware of the behavior of each implementation of #is: in the
>>> upward inheritance chain if I want to produce the proper tests. Going
>>> down,
>>> those tests will become more and more complex and hard to grok. Plus,
>>> reimplementing any of the #is: can possibly break any of the #is: in
>>> subclasses. So all #is: implementations in a given hierarchy are actually
>>> dependent. It's pure spaghetti code, as far away from OOP as it gets.
>>> I guess I'm missing something. how is this supposed to work ?
>> I think you should read mail archives.
>> First it was discussed about year ago (if i remember correctly).
> I did read the #is: proposal, at the time. No message that I remember
> addressed the kind of problem I expose above and that I had already in mind
> (although I did not participate in the discussion).
see above. Give me the reason, why a Morph subclass may want answer
false to isMorph message.

> Now I would appreciate a simple answer about what's wrong in my example; if
> there is confusion at this level, the #is: idea is certainly not as
> straightforward as it may seem.
>> Then Juan added it into Cius, cleaning a lot of isXXX method.
>> I think, we can ask Juan, how he feels about it, because he's the only
>> one who employed this idea so far.
> So it may be only a nice idea untested in a real situation. I am very
> dubious about its actual value; for one thing, it certainly cannot replace
> the isXXX I use in my own code.
Certanly , you can. In same way, as you can replace 100 named instance
variables in your class
with variable class, having 100 elements.

> regards,
> Stef

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list