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: 1108a1,371d317eff97da58 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10a640,9ca80649c409e17e X-Google-Attributes: gid10a640,public X-Google-Thread: 103376,97482af7429a6a62 X-Google-Attributes: gid103376,public From: ka@socrates.hr.att.com (Kenneth Almquist) Subject: Re: Multiple dispatch (was Re: C++ not OOP?) Date: 1995/04/19 Message-ID: #1/1 X-Deja-AN: 101106254 sender: news@nntpa.cb.att.com (Netnews Administration) references: <3mbmd5$s06@icebox.mfltd.co.uk> organization: AT&T newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.clos Date: 1995-04-19T00:00:00+00:00 List-Id: 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.