home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / ada / 2435 < prev    next >
Encoding:
Internet Message Format  |  1992-08-25  |  4.8 KB

  1. Path: sparky!uunet!olivea!sgigate!sgiblab!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!usc!rpi!bu.edu!inmet!spock!stt
  2. From: stt@spock.camb.inmet.com (Tucker Taft)
  3. Newsgroups: comp.lang.ada
  4. Subject: Re: Ada 9x Dispatching Question
  5. Keywords: Ada Dispatching Polymorphism
  6. Message-ID: <1992Aug25.160540.21034@inmet.camb.inmet.com>
  7. Date: 25 Aug 92 16:05:40 GMT
  8. References: <9223120.6784@mulga.cs.mu.OZ.AU> <1992Aug21.145044.5567@inmet.camb.inmet.com> <9223503.26777@mulga.cs.mu.OZ.AU>
  9. Sender: news@inmet.camb.inmet.com
  10. Organization: Intermetrics Inc, Cambridge MA
  11. Lines: 92
  12. Nntp-Posting-Host: spock
  13.  
  14. In article <9223503.26777@mulga.cs.mu.OZ.AU> 
  15. fjh@mundil.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  16.  
  17. >stt@spock.camb.inmet.com (Tucker Taft) writes:
  18. >
  19. >>In article <9223120.6784@mulga.cs.mu.OZ.AU> 
  20. >>fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
  21. >>
  22. >>>bwhite@cobra.camb.inmet.com (Bill White) writes:
  23. >>>
  24. >>>>Tucker believes that
  25. >>>>it is important to have a syntactic marker to tell when a call is
  26. >>>>dispatching.  An alternative rule would be the C++ rule, where all
  27. >>>>dispatching operations dispatch always.  (Ada9X dispatching operations
  28. >>>>are roughly equivalent to C++ virtual operations.)  This means that the 
  29. >>>>compiler could not replace a dispatching call with a non-dispatching
  30. >>>>call even if the compiler knows where the routine is going to go
  31. >>>>anyway.  This is considered expensive.
  32. >[...]
  33. >>The Ada 9X approach is consistent with the way derived types
  34. >>work in Ada 83, with the addition of the "class-wide" alternative.
  35. >
  36. >So am I correct in understanding that the reason for having the syntactic
  37. >marker is to maintain consistency with the rest of the language, rather
  38. >than because the alternative are "considered expensive"?
  39.  
  40. The real question is what should be the default, static
  41. binding or dynamic re-dispatch.  We have chosen to make the
  42. default static binding, which is consistent with the way
  43. derived types work in Ada 83.  Certainly dynamic re-dispatch
  44. incurs a little more overhead at run-time, but the main reason
  45. for choosing static binding as the default was really somewhat different.
  46.  
  47. Imagine you are trying to reuse a type by inheriting from
  48. it, and some of its primitive operations work "just right" while others
  49. you want to change somewhat.  If in fact one of the primitive
  50. operations that works "just right" actually uses dynamic
  51. redispatch to one of the operations that you want to change,
  52. then it will likely no longer work "just right" when you
  53. are through.  Therefore, we felt that dynamic redispatch
  54. must be seen as part of the *interface* to a primitive operation.
  55. That is, it is important to visibly define the functionality of
  56. such and operation as being defined in terms of some other operation.  
  57.  
  58. Let's take a simple example:
  59.  
  60.     Presume we have some abstract numeric type, with
  61.     two primitive operations:
  62.  
  63.        procedure Display(X : Number; R : Radix := 10);
  64.          -- Produces XXXX if R = 10, and R#XXXX# if R /= 10
  65.        procedure Display_In_Hex(X : Number);
  66.          -- Produces 16#XXXX#
  67.  
  68. Now it is not clear from looking at these whether they
  69. are implemented independently, or whether one calls the other.
  70. Now suppose you like the way that Display works, but you
  71. want Display_In_Hex to produce the hex value without the surrounding
  72. "16#" ... "#" stuff.  So you happily inherit from this Number
  73. type, and override the Display_In_Hex operation.
  74. Unfortunately, you discover later that the "Display" operation is
  75. now producing a different result when given a Radix of 16, namely
  76. that produced by Display_In_Hex.  Apparently Display dynamically
  77. redispatches to Display_In_Hex when Radix = 16.
  78.  
  79. Of course, the opposite situation might also apply.  You *want*
  80. both Display and Display_In_Hex to start showing hex values
  81. without the 16#...# stuff, and wouldn't it be nice if you
  82. only had to override one of them.
  83.  
  84. In either case, the fact that one is implemented by a dynamic
  85. redispatch to the other should be included in the interface specification.
  86. Because of that, we feel that it is reasonable that a dynamic
  87. redispatch requires a little more (visible) effort.
  88.  
  89. You might want to try to find an interesting article by DeWayne
  90. Perry in an old issue of JOOP (I am afraid I have lost the
  91. full reference -- perhaps some other newsey remembers?) that 
  92. described the issue of testing a system built using inheritance.  
  93. The problem of dynamic redispatch can make testing much more 
  94. challenging.  This observation seems to add support to the
  95. idea that dynamic redispatch should be easily visible in the source.
  96.  
  97. >Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
  98. >This .signature VIRUS is a self-referential statement that is true - but 
  99. >you will only be able to consistently believe it if you copy it to your own
  100. >.signature file!
  101.  
  102. S. Tucker Taft   stt@inmet.com
  103. Ada 9X Mapping/Revision Team
  104. Intermetrics, Inc.
  105. Cambridge, MA  02138
  106.