[squeak-dev] Additional comments on Object>>is:

Andreas Raab andreas.raab at gmx.de
Fri Mar 5 03:57:26 UTC 2010


Hi -

Here are some additional comments on the issue of Object>>is: that I'd 
like to bring forward:

1) I think about Object>>is: more as a generic membership test than a 
protocol or inheritance test. This is why (for example) I would expect 
to be able to do stuff like:

	Smalltalk is: #Squeak. "true on Squeak, false elsewhere"
	Smalltalk is: #Cuis.   "true on Cuis, false elsewhere"

There is no protocol called #Squeak; it's just a property that we 
consider to be present on Smalltalk and able to test for. Consequently, 
I'd expect objects by default to carry various tags, some static, some 
dynamic.

2) I think people got way too side-tracked by my use of #isKindOf: which 
was a simple implementation for something that should've read more like 
this:

Object>>is: aSymbol
	^self class isInstanceTag: aSymbol

and then:

Behavior>>isInstanceTag: aSymbol
	"Answer true if our instances should generically be considered to be 
tagged by the given symbol. We consider instances tagged by the names of 
their classes."

	"Here is a clever trick to avoid searching the entire class hierarchy 
when the symbol doesn't identify a class name. Instead of traversing the 
hierarchy, we look up the symbol from our environment and only if it's 
present and a behavior we go on to see if we conform to the behavior. 
That's the inverse process but much faster"
	self environment at: aSymbol ifPresent:[:aGlobal|
		aGlobal isBehavior ifTrue:[^self includesBehavior: aSymbol]
	].

	^false

I think this illustrates a little better what I was intending to 
achieve. Juan - do you still feel that this is too "inheritance 
oriented" or would you feel more comfortable with this version?

3) I think compatibility is important in this area. If we can't agree 
that instances should be tagged by their corresponding classes (and 
traits) then there is an alternative for my initial problem of 
decoupling dependencies introduced via #isKindOf: by allowing #isKindOf: 
to take a symbol as the argument. So instead of aMorph isKindOf: 
SketchEditorMorph we'd use aMorph isKindOf: #SketchEditorMorph.

This certainly avoids the dependency and I'd be okay to use it. However, 
actually taking the numbers in Cuis points out that 19 out of 21 
implementors of #is: use their class name as the only tag (I haven't 
looked at the 130 or so senders but I suspect a very similar ratio). In 
other words, we have a > 90% correlation between the use of #is: and the 
receiver's type. Given that high correlation I think it's worthwhile to 
support it out of the box.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list