On Wed, 28 May 2003 22:55:55 -0700, Joel Shellman <joel at ikestrel.com> 
wrote:

>> > However, that same distinction can be made for any class: 1) is an
>> > instance of MyClass, 2) is not an instance of MyClass.
>>
>> Firstly, #isFoo should not be about any particular class. It should be
>> about the behavioral protocol supported by a receiver of #isFoo.  To 
>> care
>> about the class of an object violates encapsulation.
>
> I was simply saying that if you're talking about distinctions than why
> doesn't the same logic apply to other distinctions?

Conceptually, it does.  In practice, it doesn't.  Adding an #isFoo method
for every possible distinction is not practical--just as adding every
conceivably useful class to an image is not practical.

>> If the question is whether or not adding an #isFoo method to Object is
>> a priori a violation of good design principles--specifically, the
> principle
>> that classes should only have methods whose domain naturally includes or
>> involves instances of the class--then the answer is an unequivocal no.
>
> Why?

Because it would result in too many methods in Object, most of which would
make distinctions involving rather esoteric protocols that are not widely
or generally used, and where it is far easier and more elegant to add a
method to Foo that does the right thing, instead of adding #isFoo to Object
so that other objects can do the right thing with instances of Foo.

Adding methods to SmallInter or Symbol that "do the right thing" in
the case of performing operations involving SmallIntegers or Symbols
would result in a large number of rather esoteric methods being added
to SmallInteger and Symbol--because both those classes are so fundamental
and widely used.  So for both those protocols, it is better to have
#isSymbol and #isInteger methods in Object.  However, in the case of
Esoteric, it is better to add a #performProtocolDependentOp method to 
Esoteric,
and move the protocol-dependent code to that method (invoked when needed
by sending #performProtocolDependentOp to the appropriate objects),
instead of adding #isEsoteric to Object and having protocol-dependent
logic send #isEsoteric as necessary.

>> I would prefer to use #conformsToProtocol: as the general mechanism for
>> discovering
>> whether or not any object conforms to any particular protocol, and 
>> reserve
>> #isFoo
>> for the most commonly used cases (because of the speed advantage.)
>
> Why not use #conformsToProtocol always (which is #4 that I suggested)? 
> Why
> is there a speed advantage with #isFoo? Conceptually (to me) both are
> dictionary lookups and that's it. I would think either could be equally 
> as
> fast. And considering the protocol dictionary would be smaller than the
> method one, protocol might could be faster.

Sending #isFoo involves only one dictionary lookup: the one needed to 
dynamically dispatch the #isFoo message.  Sending #conformsToProtocol:
involves at least two dictionary lookups--one of which is not done
primitively by the VM, which means that many message sends occur in order
to perform the image-side Dictionary lookup. It is considerably faster to 
send #isFoo.

--Alan
-- 
The Stupid Party thinks everyone else is evil.  The Evil Party thinks 
everyone else is stupid.