> Let's say we have a "map"-like object, with two methods that lookup values
> based on a key.  Unfortunately, some class designer, who enjoyed the
1960's
> a bit too much, added two different methods by which to lookup values. One
> is called #atStringKey: and the other is called #atTextKey:.  The first
one
> will only work right if the argument is a String, and the second will only
> work right if the argument is a Text (this is bizarre, of course, but that
> reflects my belief that these situations usually result because of
> someone's
> bad design.)

One problem is your example is contrived. The "correct" solution is to
rewrite/replace map with one that acts logically on any key. In other words,
even if you successfully argued that this situation justified something, you
would simply be justifying bad design because of bad design which isn't
really all that meaningful (to me anyway).

Ack, I've worked on this a while, but I can't seem to adapt this to a real
example. I keep getting back to "but you wouldn't write a map like that" or
some such thing. Sorry, but it's too late tonight, I suppose. Is there a
good real example we could examine?

> > 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.
>
> The #respondsTo: method is just as bad as checking for inclusion of a
> protocol name
> in a Set of protocols: it attempts to look up the method in the
> MethodDictionary by actually sending the #includesKey: message to a
> Dictionary, instead of doing the lookup entirely in the VM (as is done in
a
> message send.)  And of course, #includesKey:
> is implemented by sending yet other messages, which are implemented by
> sending
> yet other messages, and so on.  The same is true of #includes:, which is
> what would
> be used to check whether a protocol name is a member of a Set of protocol
> names.

That's why I said "should be able to have the same performance". I did check
current implementation and was surprised. It should be able to use the same
code that is used for method dispatch (it does the same thing after all,
just less). It just isn't right now. But that can be changed (as far as I
know anyway, which admittedly isn't necessarily too far) and so my point
holds (except that it is two method dispatches instead of one). Considering
performance of method dispatches (which is apparently really fast), I would
think two instead of one is a very minimal performance difference especially
for something that should happen rather seldom. I read a thread on
comp.lang.smalltalk about this and some were saying simply that you should
never need #isFoo so the whole discussion was a non-issue to them. Though
actually, we've moved back into discussing the other cases besides the #is*
methods. There are kind of four cases I think now that I'm beginning to
understand:

Object>>#is* - I listed some options, I'm still not sure which is best
Object>>#as* - use new or factory instead
Object>>#inspect (aka things that are specifically important to all
objects) - belongs there I think
Object>>#inform (aka shortcuts) - doesn't belong there

> Type some example code into a workspace, and use the debugger to step
> through the entire
> thread of execution involved in performing a #respondsTo: operation.
Count
> the number
> of message sends.  You'll be surprised.

Just because current implementation of something isn't optimized isn't an
excuse to exclude it from consideration. If it can be optimized, then it
would work. If someone started doing it that way, then it would probably get
optimized.

-joel