isKindOf: vs. isClassX methods
Andreas Raab
Andreas.Raab at gmx.de
Thu Oct 11 05:13:53 UTC 2001
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
More information about the Squeak-dev
mailing list
|