[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