Eddie,
  The use of "isKindOf:" may just start another religious war.  So, I will offer
my 2 cents.
  Delighted to see that you benchmark the statements and also explore the image
for usuage.
  In the ideal object world, one would never need #isKindOf:.  However, in the
practical world the need arises frequently to use #isKindOf:.  Stepping through
the execution of #isKindOf: shows that the tree is build from scratch on each
time #isKindOf: in sent.  Therefore, if the tree can be consider static then the
use of something like #isInteger certainly saves time but is also very
appropiate because the tree should not be changing.  All senders and
implementators are also easy to locate in case one whats to check on the side
effects when changing the tree.  One could use #isKindOf: Integer but then when
you look for senders or implementators you have many things to weed out that you
are not really interested in knowing about.  #isInteger and its implementors
make a very clear statement about the intent and I thinks adds to the
readibility of the code.
  Personally, using #isKindOf: during development is okay if you are still
working out what to do.  But in most places when one finds it in the image,
someone was just lazy and never changed in to isClassX.
  Hope this helps!
Phil

Eddie Cottongim wrote:

> I've noticed in many places in the image there are methods such as isColor
> or isMorph that identify the 'type' of an object. (See: Object category
> testing, Morph category classification). I always thought that this kind of
> test was done with "isKindOf:".
>
> isClassX method
> pros: allows you to identify the 'type' of an object arbitrarily (not
> strictly from the inheritance tree), faster
> cons: clutter, possibly encourages a programming style that wants a
> too-specific kind of object (this argument seem weaker the more I think
> about it-any construct can be used poorly if you try hard enough)
>
> isKindOf:
> pros: more general & uniform
> cons: slower
>
> "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
>
> Another way to look at it, isClassX puts the burden of type identification
> on the object being questioned, isKindOf puts it on the object that wants to
> know.
>
> 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 ?
>
> Thanks,
> Eddie