Re: Multiple dispatch (was Re: C++ not OOP?)

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <3n1als$ksi@no-names.nerdc.ufl.edu> kem@prl.ufl.edu (Kelly Murray) writes:

 > But we have a device that can do a draw-line real fast, so we want to
 > use it when we can, for example, on a square shape.  We must know that
 > a shape can provide the line information.  Thus, the draw method is
 > really specialized for not a square, but a lined-shaped object which
 > a square should inherit from, and return

 >  (defmethod draw ((dev line-device) (shape lined-shape))
 >    (dolist (line (shape-lines shape))
 >     (draw-line dev line)))

 > I believe this is basically the same strategy that Robert Eachus
 > has outlined.  I don't see how it could fit easily into a 
 > single-dispatch model.  Which object is doing the dispatching?
 > Do we make the device explicitely ask the shape at run-time 
 > if it can support a given operation? :

   No.  I may not have explained it well.  Let me see if I can use
your example to elucidate.  First, in Ada 95--and in some other
OO-languages--objects may be passed as non-dispatching parameters,
then used internal to the called procedure to dispatch on.  So you can
end up doing two-level dispatching, in this case first on the shape,
then on the device.

   If you specified drawing a square in terms of drawing four lines:

   procedure Draw(S: Square; L: Location; D: Device) is
   begin
      Draw_Line(Make_Line(S.Side,Horizontal),L, D);
      Draw_Line(Make_Line(S.Side,Vertical),L, D);
      Draw_Line(Make_Line(S.Side,Vertical),L+Horizontal_Displacement(S.Side),
           D);
      Draw_Line(Make_Line(S.Side,Horizontal),L+Vertical_Displacement(S.Side),
           D);
   end Draw;

   If we defined Line and Point as part of the primitive set of
operations for all devices, this is all we have to do to add drawing
squares.  (Notice that in Ada 95, the dispatching parameter can be
located anywhere in the parameter list.) Regular pentagons might be a
bit more work, but the principle is the same.

   (Note that to make things neater, you probably have some
definitions of the form:

   procedure Draw(S: Line; L: Location; D: Device) is
   begin Draw_Line(S,L,D); end Draw;

   to do the outer dispatch where the shape to be drawn is a run-time
parameter.  This is the "extra" bookkeeping required by not having
multiple dispatch in the language.) 

   Now when adding a new device, the requirements might be to provide
definitions for Point, Line, Circle, and Cubic_Spline.  Other
primitives could be provided if easily supported--say Ellipse,
Parabola, and Polygon, and even possibly Square and Rectangle--but
these would have default definitions in terms of the other primitives.
The definitions would be overridden if there was a more efficient
direct implementation for some device, and then only if you wanted the
extra efficiency.

  > Or make the shapes explicitely check for the fast operations?

    No, that should be implicit in the call tree.  In the above
example, Draw for a Square calls Line.  If for some device, Line
calls Point, that will occur within Line.  If there was a default
Square definition and it was overridden for some device, fine.

    An alternative is to have two ways to draw some shape, and have a
nested case statement to choose the "better" method based on the
device.  Seems like a maintenance nightmare, but the only damage done
if version control fails is that the less efficient method will be
used.

  > To add a device or shape, create a new index, and a bigger table.

   Arrrgh!  In my model you should never have to "recompile the
world."



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...