home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / ada / 3317 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  2.3 KB
  1. Xref: sparky comp.lang.ada:3317 comp.object:4280
  2. Newsgroups: comp.lang.ada,comp.object
  3. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!elephant.cis.ohio-state.edu!weide
  4. From: weide@elephant.cis.ohio-state.edu (Bruce Weide)
  5. Subject: Re: OOD, Ada, and Inheritance
  6. Message-ID: <1992Nov20.152625.2770@cis.ohio-state.edu>
  7. Sender: news@cis.ohio-state.edu (NETnews        )
  8. Organization: The Ohio State University Dept. of Computer and Info. Science
  9. References: <1992Nov11.042043.9740@inmet.camb.inmet.com> <1992Nov13.203723.26049@cis.ohio-state.edu> <1992Nov13.224508.18746@beaver.cs.washington.edu>
  10. Date: Fri, 20 Nov 1992 15:26:25 GMT
  11. Lines: 32
  12.  
  13. In article <1992Nov13.224508.18746@beaver.cs.washington.edu>
  14. chambers@cs.washington.edu writes (the only response so far to my
  15. request for "good" examples of the need for dynamic selection among
  16. multiple implementations of the same abstraction):
  17. >
  18. >In my implementation of the Self compiler, I use "run-time selection
  19. >among different implementation" to good effect in several data
  20. >structures.  One of the simplest is a collection of parse tree classes
  21. >(in C++), each for a different kind of language construct.  Simulating
  22. >this in Ada would require tagged variant records or something, without
  23. >behavior attached to each variant.  A more complex data structure is a
  24. >control flow graph, with different classes for each kind of CFG node
  25. >(e.g. add, branch, merge).  All CFG nodes support a common protocol,
  26. >but with widely-varying implementations.  No node knows what kind of
  27. >node is its successor or predecessor, only its interface.
  28. >
  29.  
  30. Craig, I don't really understand this example very well as an
  31. illustration of the problem at hand.  Perhaps by "multiple
  32. implementations" we mean two different things?  I'm thinking of an
  33. interface as defining a SINGLE abstract behavior -- not just method
  34. name and parameter profile, but also a specification of that behavior
  35. in implementation-neutral terms.  Any such behavior might have more
  36. than one possible implementation.
  37.  
  38. It sounds like you might be thinking of multiple SIMILAR BUT NOT
  39. IDENTICAL abstract behaviors, and considering them to be different
  40. "implementations" of the same "protocol."  Is this a correct
  41. assumption?
  42.  
  43. Cheers,
  44.     -Bruce
  45.