[squeak-dev] Additional comments on Object>>is:
andreas.raab at gmx.de
Fri Mar 5 03:57:26 UTC 2010
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
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
^self class 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
"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]
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.
More information about the Squeak-dev