Andreas Raab wrote:
> 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.

Yes. The question is where to stop. #is: could be used to replace any 
method that is a test for a boolean value. I guess going too far in this 
direction could bring the issues raised by Stephane, like putting too 
much meanings in a single method. For example, so far in Cuis I replaced 
#isHandMorph with #is: HandMorph, but I did not replace #isWorldMorph, 
because #isWorldMorph is dynamic. So far I only replaced methods that 
just answer the true or false constant. I guess we'd need some 
experience with actual use to know where to draw the limit of what's 
good and what's bad to do in #is: .

>
> 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?

This is better than the previous version. And it is quite reasonable if 
you lean towards generic membership, including dynamic membership, and 
not just protocols.

> 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.

Making #isKindOf: accept symbols is better than adding #isA:. Anyway, in 
an ideal world, we'd never need to test for class membership, except, 
perhaps, for a few low level operations that deal specially with special 
kernel classes.

> 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

Right. So far I only used #is: to replace #isXXX methods, so it is 
pretty much belonging to a class (actually to a hierarchy, as all 
implementors of #is: do call super). However, being able to add 
LightWidget and M3Morph on par with Morph, without having to add 
knowledge about these new Morph-like classes, is what shows me that 
thinking on protocol compliance is better than thinking on hierarchy. I 
believe that in Cuis, when real redesign takes over simply replacing a 
pattern with another, that 90% correlation could change. Only time will 
tell.

Cheers,
Juan Vuletich