[squeak-dev] Re: Object>>#is:? (was: Re: PackageDependencyTest)
Stéphane Rollandin
lecteur at zogotounga.net
Thu Mar 4 19:44:26 UTC 2010
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
then BorderedMorph must implement
is: aSymbol
(super is: aSymbol
or: [aSymbol == #BorderedMorph]) ifTrue: [^ true].
^ false
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 ?
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 ?
Stef
More information about the Squeak-dev
mailing list
|