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

[ka@socrates.hr.att.com (Kenneth Almquist)]

Robert Eachus interpreted the example problem slightly differently than
I did.  I assumed that (1) the system might have to support shapes and
devices which were very different than those anticipated when the system
was designed and (2) to achieve adequate drawing speeds it is necessary
to do a fairly good job of adapting to the capabilities of the various
devices.  Under these assumptions, Robert's design no longer guarantees
the O(1) subroutine counts he intended.

If a new shape is added, along with some devices which support an
operation specificly designed to support that shape, then to achieve
adequate efficiency (see assumption 2) it may be necessary to add a
new optional operation to Robert's design.

More seriously, suppose that there is a shape which approximates a
complex curve using a series of arc drawing operations.  Then a device
appears which can efficiently draw parabola segments but not arcs
Drawing the complex curve by generating a series of arcs which are in
turn translated into parabola segments will result in more parabola
segments than optimal.  If the result doesn't meet our performance
requirements, we have to modify the definition of the shape to query
the device and use either arcs or parabola segments as appropriate.
The design may avoid this particular problem, but assumption 1 implies
that something similar will eventually happen.

The design presented by Robert is still usable even with my assumptions.
The failure to achieve development effort proportional to the number
of features is inherent in the problem.[1]  However, it is sometimes
necessary to modify exiting shape routines rather than just add new
routines.  This is undesirable but certainly not fatal.

The problem I see with multiple dispatch is this:  Frequently it is
easy to express a high level description of a problem in terms of
multiple dispatch, but multiple dispatch normally requires you to
write too many routines.  The solution that I have been toying with is
application specific dispatch.  The idea is that you write the minimum
number of implementations of an abstract routine required to solve a
problem, and then develop an application-specific method of selecting
which implementation to call in a specific instance.  This minimizes
the number of instances at the cost of increasing the complexity of
determining which instance to call.

I think that a case can be made for the use of application-specific
multiple dispatch is the best approach for the shape-displaying
problem because it allows you to avoid modifying (as opposed to
adding) implementations of routines.  However, it is a weak case
because the application specific dispatching code may have to be
modified.
				Kenneth Almquist



[1] It might be possible to write a program which read descriptions
    of the shapes and devices, and generate code to display each
    shape on each device.  Once this program was written, the
    programmer cost to implement a feature would be O(1).  My guess
    is that this approach is not very practical.