Scott,

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

> If you're making isXYZ methods for speed reasons, don't.

Correct. Make it for all the reasons Tim gave ;-)

> Andreas, you said that you'd heard it was bad design and bad
> style. Why?

I didn't say "I've heard" but "everyone I've talked to agreed that" using
#isKindOf: is bad style. Subtle difference ;-)

The reason is simply that you are *never* interested in the type (e.g.,
class) of the argument. All you are ever interested in is either its
interface (e.g., the set of supported protocols) or its role in the
simulation (which usually comes down to a subset of protocols).

Here's one example from practice: When I rewrote some of HandMorphs event
processing I wanted to do this in a somewhat more secure environment. So I
started from scratch and made a parallel class to HandMorph (copying all its
state and methods over there). At the beginning, this class was to 100%
identical to HandMorph. Keep in mind that because I was going to rewrite
large parts of the implementation (including changes to instance variables)
I neither wanted nor could make it a subclass of HandMorph. All I wanted was
to provide a different implementation of the very same behavior.

When I run it, various things went wrong. Surprise! Since there were clients
testing for the *type* (namely "being" a HandMorph such as in
Morph>>ownerThatIsA:) rather than its *role* (namely "acting" as a
HandMorph) or its *interface* (namely implementing the protocols of
HandMorph) my 100% exact duplicate of HandMorph didn't work as one would
expect. So what did #isKindOf: tell us? It told us "that's not a hand morph"
but in not a single place does that ever matter. All of the users of any
such stuff are *exclusively* interested in the role or the interface.

And here's why that's both bad design and bad style - you are early binding
something that may be irrelevant at this point but may very well become
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).

Cheers,
  - Andreas


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf
> Of Scott A
> Crosby
> Sent: Wednesday, October 10, 2001 6:29 PM
> To: Eddie Cottongim
> Cc: squeak-dev at lists.squeakfoundation.org
> Subject: Re: isKindOf: vs. isClassX methods
>
>
> On Wed, 10 Oct 2001, Eddie Cottongim wrote:
>
> >
> > "Simple speed test which may or may not characterize
> average case usage:"
> > m := EllipseMorph new.
> > Time millisecondsToRun: [ 100000 timesRepeat: [m
> isHandMorph] ] 60 ms
> > Time millisecondsToRun: [ 100000 timesRepeat: [m isKindOf:
> HandMorph] ] 351
> > ms
>
> First, this isn't good benchmarking. isKindOf is fairly assymetric, in
> that it can be a lot more expensive when the result is false
> then when it
> is true. Thus, any cache needs to cache negative results too.
>
> But, I'd not be concerned about this performance at all. This is still
> 300,000 isKindOf's per second. I doubt any code is going to
> use it this
> much, but, if profiling does find code that does use it
> enough that this
> is consuming CPU time, the correct fix isn't to create a strange
> workaround, but rather to speed up this operation. Make an isKindOf:
> lookup cache, or do the work in a primitive. (Use a bytecode
> and a cache
> and I think you can make isKindOf faster than a method invocation.)
>
> IE, I wouldn't worry one whit about it being slower; if
> necessary, this
> change might make 'isKindOf:' faster than 'isHandMorph'. If
> you're making
> isXYZ methods for speed reasons, don't.
>
> BTW, why do the isXYZ functions exist? Why not use isKindOf.
> They both do
> the same thing, but one creates a lot of extra methods in Object, and
> other big base clases that already have too many methods.
>
> Other people have said that isKindOf is 'bad style', but is
> isHandMorph
> any better? They both do the same thing and both solve the
> same sort of
> problem, basically, multimethods.
>
> (Multimethods are when you wish to do dynamic dispach based
> on more than
> one argument to a function. For example:
>   Foo, Bar are subclasses of Collection
>    Foo>>quickAppend: aBar.
>    Foo>>quickAppend: aFoo.
>    Bar>>quickAppend: aFoo.
>    Bar>>quickAppend: aBar.)
>
> Andreas, you said that you'd heard it was bad design and bad
> style. Why?
>
> > I've always stuck with isKindOf in my work beacuse I
> thought it was the
> > "right thing" to do. I'm guessing that the testing methods
> in Object, Morph
> > etc are there for speed reasons. So, as a programmer, I
> should start with
> > isKindOf and create explicit methods if isKindOf is a speed
> bottlenect. Am I
> > missing any other considerations ?
>
>
> IMO, continue to do the right thing, only worry about speed
> of isKindOf if
> and only if profiling does show it to be a problem. And even
> if, at some
> future point isKindOf does become a problem, implement one of the
> speedups.
>
> BTW, this also applies to respondsTo:, that can make that
> fairly cheap in
> exactly this fashion.
>
> If performance considerations are why we don't use respondsTo: or
> isKindOf:, next month I can work on a a cache, and a slang plugin to
> automate it.
>
>
> Scott
>
>
>
> --
> No DVD movie will ever enter the public domain, nor will any
> CD. The last CD
> and the last DVD will have moldered away decades before they
> leave copyright.
> This is not encouraging the creation of knowledge in the
> public domain.
>
>
>
>
>