home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / ada / 3319 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  3.2 KB
  1. Xref: sparky comp.lang.ada:3319 comp.object:4286
  2. Newsgroups: comp.lang.ada,comp.object
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!uw-beaver!klamath.cs.washington.edu!chambers
  4. From: chambers@klamath.cs.washington.edu (Craig Chambers)
  5. Subject: Re: OOD, Ada, and Inheritance
  6. Message-ID: <1992Nov20.202816.27409@beaver.cs.washington.edu>
  7. Sender: news@beaver.cs.washington.edu (USENET News System)
  8. Reply-To: chambers@cs.washington.edu
  9. Organization: University of Washington
  10. References: <1992Nov11.042043.9740@inmet.camb.inmet.com> <1992Nov13.203723.26049@cis.ohio-state.edu> <1992Nov13.224508.18746@beaver.cs.washington.edu> <1992Nov20.152625.2770@cis.ohio-state.edu>
  11. Date: Fri, 20 Nov 92 20:28:16 GMT
  12. Lines: 48
  13.  
  14. In article <1992Nov20.152625.2770@cis.ohio-state.edu>, weide@elephant.cis.ohio-state.edu (Bruce Weide) writes:
  15. |> In article <1992Nov13.224508.18746@beaver.cs.washington.edu>
  16. |> chambers@cs.washington.edu writes (the only response so far to my
  17. |> request for "good" examples of the need for dynamic selection among
  18. |> multiple implementations of the same abstraction):
  19. |> >
  20. |> >In my implementation of the Self compiler, I use "run-time selection
  21. |> >among different implementation" to good effect in several data
  22. |> >structures.  One of the simplest is a collection of parse tree classes
  23. |> >(in C++), each for a different kind of language construct.  Simulating
  24. |> >this in Ada would require tagged variant records or something, without
  25. |> >behavior attached to each variant.  A more complex data structure is a
  26. |> >control flow graph, with different classes for each kind of CFG node
  27. |> >(e.g. add, branch, merge).  All CFG nodes support a common protocol,
  28. |> >but with widely-varying implementations.  No node knows what kind of
  29. |> >node is its successor or predecessor, only its interface.
  30. |> >
  31. |> 
  32. |> Craig, I don't really understand this example very well as an
  33. |> illustration of the problem at hand.  Perhaps by "multiple
  34. |> implementations" we mean two different things?  I'm thinking of an
  35. |> interface as defining a SINGLE abstract behavior -- not just method
  36. |> name and parameter profile, but also a specification of that behavior
  37. |> in implementation-neutral terms.  Any such behavior might have more
  38. |> than one possible implementation.
  39. |> 
  40. |> It sounds like you might be thinking of multiple SIMILAR BUT NOT
  41. |> IDENTICAL abstract behaviors, and considering them to be different
  42. |> "implementations" of the same "protocol."  Is this a correct
  43. |> assumption?
  44. |> 
  45. |> Cheers,
  46. |>     -Bruce
  47.  
  48. Yes, that's what I'm describing.  I've forgotten the original question
  49. by now, but my response was providing a concrete example for dynamic
  50. binding and inclusion polymorphism as commonly found in OO languages.
  51. The alternative (at least in Ada) is quite painful.  In any case, I
  52. don't recall why you're interested in the restricted subcase of
  53. providing multiple implementations with *identical* abstract behavior.
  54. I'm sure it's less common and less useful than collections of
  55. implementations with related abstract behavior.  An example of
  56. multiple implementations with identical behavior is multiple
  57. implementations of a key-value table (lists of pairs or hash tables);
  58. both have the same abstract behavior but different performance
  59. tradeoffs for large and small tables.
  60.  
  61. -- Craig Chambers
  62.