home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / ada / 3341 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  4.8 KB
  1. Xref: sparky comp.lang.ada:3341 comp.object:4306
  2. Newsgroups: comp.lang.ada,comp.object
  3. Path: sparky!uunet!zaphod.mps.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: <1992Nov23.201013.23829@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: <1992Nov13.224508.18746@beaver.cs.washington.edu> <1992Nov20.152625.2770@cis.ohio-state.edu> <1992Nov20.202816.27409@beaver.cs.washington.edu>
  10. Date: Mon, 23 Nov 1992 20:10:13 GMT
  11. Lines: 78
  12.  
  13. In article <1992Nov20.202816.27409@beaver.cs.washington.edu>
  14. chambers@cs.washington.edu writes:
  15. >
  16. >... I've forgotten the original question
  17. >by now, but my response was providing a concrete example for dynamic
  18. >binding and inclusion polymorphism as commonly found in OO languages.
  19. >The alternative (at least in Ada) is quite painful.  In any case, I
  20. >don't recall why you're interested in the restricted subcase of
  21. >providing multiple implementations with *identical* abstract behavior.
  22. >I'm sure it's less common and less useful than collections of
  23. >implementations with related abstract behavior.  An example of
  24. >multiple implementations with identical behavior is multiple
  25. >implementations of a key-value table (lists of pairs or hash tables);
  26. >both have the same abstract behavior but different performance
  27. >tradeoffs for large and small tables.
  28. >
  29.  
  30. I could not agree that having multiple implementations for the same
  31. abstract behavior is "less common and less useful than collections of
  32. implementations with related abstract behavior."  That this may be
  33. less common (at least among OO enthusiasts :-) is not so debatable or
  34. so important.  The more important question is what we SHOULD have.
  35.  
  36. There are two issues.  First, why do we want to have multiple
  37. implementations for the same abstract behavior?  Performance
  38. trade-offs, as Craig points out with a good example above.  Enough
  39. said... except for the question of good examples where we want to
  40. choose among these various implementations dynamically.  I can imagine
  41. such, but they seem rather less plentiful than the number of
  42. situations in which one might like to be able to choose performance
  43. characteristics somewhat independently of abstract functionality, but
  44. still at compile time.  If anyone has good examples for this dynamic
  45. situation I'd be grateful.
  46.  
  47. Second, why do we NOT want to treat collections of classes/objects/
  48. whatever exhibiting SIMILAR abstract behaviors, as though they were
  49. just multiple implementations of "related abstract behavior"?  It's a
  50. question of where you draw the line; what's similar and what isn't?
  51. Oh, I know you can define this precisely in terms of language
  52. mechanisms.  But what about MEANING?
  53.  
  54. To make this question more precise...  One of the main reasons for
  55. abstraction is to provide an implementation-neutral explanation of how
  56. a component is going to behave (functionally) in a client program --
  57. precisely so the client does not have to examine the source code for
  58. the implementation in order to know WHAT the component is going to do.
  59. The client's going to have a hard time reasoning about his/her
  60. program's behavior in this way if the ACTUAL ABSTRACT BEHAVIOR of the
  61. component that is observable by the client differs (even slightly)
  62. from one moment to the next during program execution, as different
  63. implementations with "similar but not identical abstract behavior" are
  64. invoked for the "same" operation.
  65.  
  66. Maybe this doesn't matter too much for "small" or "prototype"
  67. software, but for industrial-strength software in life-critical
  68. applications...  Well, I'm reminded of the line from Ghostbusters that
  69. goes something like, "You don't often see behavior like that in a
  70. major appliance."  Let's hope not.  But how is occasionally bizarre
  71. behavior going to be avoided if our informal reasoning about client
  72. program behavior is unsound and/or incomplete (in the logical sense)?
  73. That's the inevitable consequence of saying that SOME (ANY) of the
  74. abstract behavior exhibited by the dynamically chosen implementation
  75. is not known until run-time.
  76.  
  77. So I now rephrase the original question: Can someone give me a good
  78. example of a case where one wants to have multiple implementations for
  79. SIMILAR but NOT IDENTICAL abstract behaviors, AND for which this
  80. abstract behavior is specified formally and in implementation-neutral
  81. terms (or at least could be in principle)?  Although I just argued
  82. against this, I think there may be some (and I may even know some),
  83. but I'm interested in what those in the OO community would consider
  84. good examples of this situation.  As part of the example I would, of
  85. course, expect to see the abstract specification of that part of their
  86. behavior that these different implementations would all have in
  87. common.
  88.  
  89. Cheers,
  90.     -Bruce
  91.