From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 109fba,97482af7429a6a62
X-Google-Attributes: gid109fba,public
X-Google-Thread: 10a640,9ca80649c409e17e
X-Google-Attributes: gid10a640,public
X-Google-Thread: 1108a1,371d317eff97da58
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,97482af7429a6a62
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Multiple dispatch  (was Re: C++ not OOP?)
Date: 1995/04/21
Message-ID: <EACHUS.95Apr21102220@spectre.mitre.org>#1/1
X-Deja-AN: 101368870
references: <dewar.797512974@gnat> <3mbmd5$s06@icebox.mfltd.co.uk>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.clos
Date: 1995-04-21T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <D79o2K.K0o@nntpa.cb.att.com> ka@socrates.hr.att.com (Kenneth Almquist) writes:

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

    Hmmm.  I certainly agree with (1), I'll argure from practical
experience that my approach does deal with (2).  You just need a "rich"
enough set of optional primitives to cover the set of possible engines.

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

   Agreed, but this is not a limitation.  If you look at what you are
saying, it is that evolving requirements may result in an evolving
design.  But there is no need for massive restructuring in this
case--you add the new shape, and the "optional" primitive that you
need to define it, say Bessel functions, and a (base) implementation
in terms of other primitives.  At this point in Ada 95 you need to do
a "global" recompile because you have added a dispatching operation.
Then add each new device as usual.  Of course given the stated
assumptions you have additional work on each one because you want to
map the Bessel operation specially for each of these devices.

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

   I totally agree.  During the Ada 9X development process, I actually
looked at the advantages and disadvantages of supporting multiple
dispatch.  It could have been done, but there are precious few cases
where the additional generality buys anything, and the educational
overhead is there forever.

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

   Don't do that! ;-)  Seriously, in Ada the best way of satisfying
this need is with generic instantiation.  I can (and do) have a
library of several sorts with the same generic interface.  But rather
than letting some AI routine select the best one, I, as the designer,
choose the best sort for this application.

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

     Depends on your definition of practical.  It looks like a pretty
good description of how curses works, except that curses does it more
dynamically.


--

					Robert I. Eachus

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