2010/3/4 Stéphane Rollandin <lecteur at zogotounga.net>:
> I don't see how #is: can work in the large.
>
> suppose I need test selectors like isMorph, isBorderedMorph, isMyMorph and
> isMySpecializedMorph
>
> every Morph must have
>
> is: aSymbol
>        aSymbol == #Morph ifTrue: [^ true].
>        ^ false
>
it much not. If you seen a proposed implementation, you don't need to
have such override, since
a base method will behave exactly like that for any Morph instance.

> then BorderedMorph must implement
>
> is: aSymbol
>        (super is: aSymbol
>                or: [aSymbol == #BorderedMorph]) ifTrue: [^ true].
>        ^ false
>
same as above. You don't need to override it.

> now MyMorph (supposedly a BorderedMorph) has
>
> is: aSymbol
>        (super is: aSymbol
>                or: [aSymbol == #MyMorph]) ifTrue: [^ true].
>        ^ false
>
>
> so far so good, although at the moment all this code would be replaced with
>
> isMorph
>        ^ false
>
> isBorderedMorph
>        ^ false
>
> isMyMorph
>        ^ false
>
> in Object, and the corresponding
>
>
> isMorph
>        ^ true
>
> isBorderedMorph
>        ^ true
>
> isMyMorph
>        ^ true
>
> at the proper places
>
>
> let's now consider MySpecializedMorph, a subclass of MyMorph that I *do not*
> want to be considered as MyMorph:
>
> is: aSymbol
>        (super is: aSymbol and: [aSymbol =~ #MyMorph])
>                or: [aSymbol == #MySpecializedMorph]) ifTrue: [^ true].
>        ^ false
>
> see the problem ?
>

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.
Obviously, in your example you showing how to not abuse inheritance.
And its nothing to do with #is: method :)

> 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).
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.

>
> Stef
>


-- 
Best regards,
Igor Stasenko AKA sig.