home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!sgigate!sgiblab!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!usc!rpi!bu.edu!inmet!spock!stt
- From: stt@spock.camb.inmet.com (Tucker Taft)
- Newsgroups: comp.lang.ada
- Subject: Re: Ada 9x Dispatching Question
- Keywords: Ada Dispatching Polymorphism
- Message-ID: <1992Aug25.160540.21034@inmet.camb.inmet.com>
- Date: 25 Aug 92 16:05:40 GMT
- References: <9223120.6784@mulga.cs.mu.OZ.AU> <1992Aug21.145044.5567@inmet.camb.inmet.com> <9223503.26777@mulga.cs.mu.OZ.AU>
- Sender: news@inmet.camb.inmet.com
- Organization: Intermetrics Inc, Cambridge MA
- Lines: 92
- Nntp-Posting-Host: spock
-
- In article <9223503.26777@mulga.cs.mu.OZ.AU>
- fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
-
- >stt@spock.camb.inmet.com (Tucker Taft) writes:
- >
- >>In article <9223120.6784@mulga.cs.mu.OZ.AU>
- >>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
- >>
- >>>bwhite@cobra.camb.inmet.com (Bill White) writes:
- >>>
- >>>>Tucker believes that
- >>>>it is important to have a syntactic marker to tell when a call is
- >>>>dispatching. An alternative rule would be the C++ rule, where all
- >>>>dispatching operations dispatch always. (Ada9X dispatching operations
- >>>>are roughly equivalent to C++ virtual operations.) This means that the
- >>>>compiler could not replace a dispatching call with a non-dispatching
- >>>>call even if the compiler knows where the routine is going to go
- >>>>anyway. This is considered expensive.
- >[...]
- >>The Ada 9X approach is consistent with the way derived types
- >>work in Ada 83, with the addition of the "class-wide" alternative.
- >
- >So am I correct in understanding that the reason for having the syntactic
- >marker is to maintain consistency with the rest of the language, rather
- >than because the alternative are "considered expensive"?
-
- The real question is what should be the default, static
- binding or dynamic re-dispatch. We have chosen to make the
- default static binding, which is consistent with the way
- derived types work in Ada 83. Certainly dynamic re-dispatch
- incurs a little more overhead at run-time, but the main reason
- for choosing static binding as the default was really somewhat different.
-
- Imagine you are trying to reuse a type by inheriting from
- it, and some of its primitive operations work "just right" while others
- you want to change somewhat. If in fact one of the primitive
- operations that works "just right" actually uses dynamic
- redispatch to one of the operations that you want to change,
- then it will likely no longer work "just right" when you
- are through. Therefore, we felt that dynamic redispatch
- must be seen as part of the *interface* to a primitive operation.
- That is, it is important to visibly define the functionality of
- such and operation as being defined in terms of some other operation.
-
- Let's take a simple example:
-
- Presume we have some abstract numeric type, with
- two primitive operations:
-
- procedure Display(X : Number; R : Radix := 10);
- -- Produces XXXX if R = 10, and R#XXXX# if R /= 10
- procedure Display_In_Hex(X : Number);
- -- Produces 16#XXXX#
-
- Now it is not clear from looking at these whether they
- are implemented independently, or whether one calls the other.
- Now suppose you like the way that Display works, but you
- want Display_In_Hex to produce the hex value without the surrounding
- "16#" ... "#" stuff. So you happily inherit from this Number
- type, and override the Display_In_Hex operation.
- Unfortunately, you discover later that the "Display" operation is
- now producing a different result when given a Radix of 16, namely
- that produced by Display_In_Hex. Apparently Display dynamically
- redispatches to Display_In_Hex when Radix = 16.
-
- Of course, the opposite situation might also apply. You *want*
- both Display and Display_In_Hex to start showing hex values
- without the 16#...# stuff, and wouldn't it be nice if you
- only had to override one of them.
-
- In either case, the fact that one is implemented by a dynamic
- redispatch to the other should be included in the interface specification.
- Because of that, we feel that it is reasonable that a dynamic
- redispatch requires a little more (visible) effort.
-
- You might want to try to find an interesting article by DeWayne
- Perry in an old issue of JOOP (I am afraid I have lost the
- full reference -- perhaps some other newsey remembers?) that
- described the issue of testing a system built using inheritance.
- The problem of dynamic redispatch can make testing much more
- challenging. This observation seems to add support to the
- idea that dynamic redispatch should be easily visible in the source.
-
- >Fergus Henderson fjh@munta.cs.mu.OZ.AU
- >This .signature VIRUS is a self-referential statement that is true - but
- >you will only be able to consistently believe it if you copy it to your own
- >.signature file!
-
- S. Tucker Taft stt@inmet.com
- Ada 9X Mapping/Revision Team
- Intermetrics, Inc.
- Cambridge, MA 02138
-