On Wed, 10 Oct 2001, Andreas Raab wrote:

> Scott,
>
> You're a kidder, eh?! You can't mean seriously what you've written, but I'll
> respond to it anyways ;-)
>

I did, and thanks, it is instructive.

What it is is confusing two things, sometimes, you do care about the
actual class, because your code does need to get into the grotty
implementation. Here, using isKindOf: is important. In my case for some
code I did recently (the 33% gain with macroBenchmark1), I did need
isKindOf, in this sense of things.

But then you have the other case, where you want to know if it supports a
particular set of methods, the java notion of an interface.

I hadn't realized quite how important the second case was until your
response. Thanks!

Query, why not do what you mean instead of creating extra methods like
isXYZ?  Support something that lets you directly represent interfaces and
implementation.

Basically, create classes which inherit from Interface, then
define something that does exactly that, something like:

Object>>implementsInterface: anInterface
  anInterface class selectorsDo: [ :x | self class canUnderstand: x
ifFalse:
      [^false]].
  ^true.

Well, actually, slightly more complicated to handle interfaces inheriting
from other interfaces, but you get the idea.

And don't tell me that it'll be too slow! Cause we can do my favorite
thing: cache the results.  (If there are, say, 200 classes each of which
gets checked whether it implements, say, 4 interfaces, thats <1k of
hash table slots, say, 16kb for a cache.)

For bonus points, I could integrate this into Behavior (or whatever) and
let one verify that a class does support the interfaces it claims to
support. Further integration into browsers and other foo is not something
I wanna do. :)

Good, Bad, Tried already, or Ugly?

> important. And then you have go back and fix it at three zillion different
> places (some of which might even be out of your control).

Ouch... Your point stands, and I bask in your knowledge. :)


Scott