Scott,

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

Sorry, but you don't ;-) This behavior can be expressed using
double-dispatching which is a technique that does implement multi-method
like behavior. Rather than using

Frobler>>doMumble: anObject
	(anObject isKindOf: Foo)
		ifTrue:[^self doMumbleWithFoo: anObject].
	(anObject isKindOf: Bar)
		ifTrue:[^self doMumbleWithBar: anObject].
	^self doMumbleGeneral: anObject

you - again - rely on late-binding by telling the argument to perform a
specific service with the receiver. This would (for the above case) look
like:

Frobler>>doMumble: anObject
	^anObject doMumbleFrom: self.

Object>>doMumbleFrom: aFrobler
	^aFrobler doMumbleGeneral: self.

And now that you have these two methods in place, you can go ahead and add
methods for specific class pairs (we'll assume that doMumbleWithXYZ does
exist):

Foo>>doMumbleFrom: aFrobler
	^aFrobler doMumbleWithFoo: self.

Bar>>doMumbleFrom: aFrobler
	^aFrobler doMumbleWithBar: self.

>From the design standpoint using double-dispatching is clearly advantageous.
You can add to the general mechanism without modifying any of the existing
methods. You are not bound to the inheritance tree which would complicate
your #isKindOf: tests quite a bit (e.g., make it order dependent if you have
a subclass that requires a different optimization). You could use a specific
version from a different place if the same constraints apply (e.g., all that
is required for your copyReplace... withArray: variant is that the argument
is indexable - it does not have to be an instance of class Array). You can
disable a specific optimization if some subclass does break the constraints
(like a segmented array which stores the elements in segments).

Etc. etc. etc. Basically it's all about late-binding ;-)

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

Ever looked at SmallInterfaces?! ;-)

> And don't tell me that it'll be too slow!

Hey, *I* never raised that argument ;-) I'm a graphics guy - there *are* no
slow things just not enough computing power ;-) [Do you remember the dark
age when laptops didn't have 3D accelerators and vector processing units?!
;-]

> Good, Bad, Tried already, or Ugly?

Again, look at SmallInterfaces (sorry, don't have the URL handy). Personally
I think it's good ... but the pay-off is not large enough. By the end of the
day, it's faster and more convenient to use either one of #isXYZ or
isKindOf: XYZ and if that's the case you'll never get a weekend hacker to
use that kind of stuff.

Cheers,
  - Andreas