Double dispatch

Travis Griggs tgriggs at keyww.com
Wed Nov 4 20:57:19 UTC 1998



Gerardo Richarte wrote:

> Travis explained:
>
> > The original Squeak Math protocol does this. It works fine for the simple set
> > of Integer, Fraction, Float, where one can basically define a heirarchy of
> > supremacy.
>
>     The original Squeak Math protocol is a good implementation of mathematical
> definition for operators (find a superset containing both elements, closed for
> the operation you what to perform). Is there an example where DD is needed (and
> squeak's protocol doesn't make it).

I thought vectorized numerics made a pretty good example. :) If you use the
coercion approach, then you're left with creating 1) a collection of like size with
the single numeric element repeated (get's expensive for big collections) or 2)
creating a new kind of PseudoCollection object to model #1, without the
replication.

>     The only problem I found is that when you create a new class (such as
> AlgebraicNumber) you need to add #adaptAlgebraicNumber: and
> #adaptToAlgebraicNumber to every other class you what to interact with.

It gets worse with DD math, becuase you basically have the same thing times 4 (*,
+, - , /).


>     DD is good for speed, but it's is not good when the operation is not
> commutative, I think that a mixed solution (as usual) may be the better... Does
> anybody has an idea on how to implement such a mixed solution? I mean DD and
> #adapt* protocol.

I guess, I kind of thought of the current Squeak adaptProtocol as a DD form of
coercion. The old VW coercion architecture was not and it was worse, because you
had to give every Numericall Savvy object a rank, whichever of the two operands
scored the higher rank, got the privelage of coercing the other via the coerce:
message. If the coercion operation depended on the type of the argument though,
then you had to do case like things (though this only turns out to be a theoretical
scenario). The Squeak adapt* protocol though dispatches to the argument, with a
message that is particular to the reciever's type, which looks a lot like DD to me.

I'm not sure what you mean by your argument that DD is not good for
non-commutative. It seems well suited for an algabraic number system (having
written a crude one years ago). You want to be able to add a simple number (Float,
Integer, etc.) to an AlgebraicSymbol. So you have sumFromFloat: implemented in
AgebraicSymbol. The argument is a float. It seems very crystal clear how that
method should proceed. You also have sumFromSymbol: implemented in Float. Again,
very clear what to do. If you drive these messages using DD from the + selector
implemented in both AlgebraicSymbol and Float, you've got commutative operations
between AlgebraicSymbols and Floats. I assume you must have meant something else?

--
Travis Griggs
Key Technology
tgriggs at keyww.com
Member, Fraven Skreiggs Software Collective
 - C for Sinking
 - Java for Drinking
 - Smalltalk for Thinking





More information about the Squeak-dev mailing list