Double dispatch

Travis Griggs tgriggs at keyww.com
Wed Nov 4 17:53:25 UTC 1998



Ralph Johnson wrote:

> The best paper on double-dispatching was the one that Dan Ingalls wrote
> for OOPSLA'86.  But if you don't have the OOPSLA'86 proceedings, or the
> CD with the first ten years of papers on it, you might read the paper
> that Kurt Hebel and I wrote on it at
> ftp://st.cs.uiuc.edu/pub/papers/patterns/double-dispatch.ps
>
> Our paper focuses on how to implement arithmetic, and on a tool
> that we built to make double-dispatching easier.

Another reference is both the GOF Patterns book, or the ST Companion
version. Both give good descriptions of doube dispatching. The most common
application of DD is with reference to the Numeric protocol. If you want to
see DD math in Squeak, I've added something at the UIUC archive. There's
also a little html overview therein that gives a terse description of DD.

DD works well any time you have 2 or more object kinds which you must "mix"
via some behavior, and neither of the objects coerces readily to the other.
That last part is the key part. If you can coerce one or the other readily
to the other, then you just coerce so that both are uniform, and then apply
the "mixing" behavior (e.g. add the two). 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. But what if you
want to mix Points numerically with the simple numbers. Now the coercion
method has to create a more hefty intermediate object in the coercion
process, nevertheless, it's not too hefty. But if one wants to mix numbers
with Collections of numbers, then what to do. Do you coerce the sole number
up to an equally sized collection that contains all the same number, so
that you can add the collections piecewise? Could get expensive! This is
where DD begins to really pay off. The same is true if one adds Measured
Values to the system.

The Numeric protocol is not the ONLY place where DD works nice.
Unfortunately, I think too often people just think that's the way math is
done in Smalltalk, and forget the pattern behind it. Back when I worked in
the dieing Nuclear industry, we wrote an Engineering Analysis and Design
tool, which greatly assisted the engineer in deciding how to shuffle fuel
assemblies at the end of the cycle. In that process, old fuel assemblies
are taken out of the core and placed in the spent fuel pool to gather dust
and be dealt with later. Some of the remaining fuel assemblies are shuffled
around for power distribution reasonds. A truck (or two) comes in with
fresh fuel assemblies to load into the core. Then you have this concept
called symmetricity. The symmetricity for each reactor may be different
than the next, usually octant or quadrant (reflected either across lines or
rotated). The whole game of the tool we wrote then, was to provide a drag
and drop interface to move assemblies around. There were basically three
sites you could draw fuel from, and three sites you could place fuel at.
But the rules in each case of combination were different for each case, and
a couple weren't allowed. IOW, when moving assemblies from the truck to the
core, you had to not just add one, but it's symmetric counterparts, also
drawn from the truck. The solution (which blew the C/Fortran guys minds)
was to use DD. When a drag op started, a crane object took hold of the
assembly that was being moved. It also remembered where it had picked the
assembly from. When the drag op ended, it would end over one of the three
views. The message was the time, addFuel: aFuelAssembly from: aSite. The
reciever (one of the three sources) would then use DD to dispatch back to
aSite by typifying itself (e.g. takeFuel: aFuelAssembly forCore: aSite) and
the correct behavior would be achieved.

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