Object: Identity vs. Environment

Joel Shellman joel at ikestrel.com
Thu May 29 07:21:40 UTC 2003


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

So... you're agreeing with me to a certain degree as far as not using
#isFoo?

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

Sorry, I didn't follow what you're saying here.

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

I realized just after I sent it that it would be two as you say. So what
you're saying is that it is ONLY an optimization? If so, why not just use
Object>>#respondsTo? That should be able to have the same performance as a
method dispatch shouldn't it? It is conceptually equivalent to
Object>>#isFoo, and it still similarly distinguishes everything that is a
Foo and everything that isn't. This sort of thing is the equivalent of
marker interfaces in Java.

-joel



More information about the Squeak-dev mailing list