[squeak-dev] Re: Object>>#is:? (was: Re: PackageDependencyTest)
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:
^ 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
>>> 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.
Igor Stasenko AKA sig.
More information about the Squeak-dev