On 4 March 2010 22:08, Igor Stasenko <siguctua at gmail.com> wrote:
> 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.

or hot to abuse it.. whatever.
I meant: in your example you having a problems not because of #is:
method, but because of abuse of 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.
>



-- 
Best regards,
Igor Stasenko AKA sig.