home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / ada / 2584 < prev    next >
Encoding:
Text File  |  1992-09-10  |  3.5 KB  |  86 lines
  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!cis.ohio-state.edu!news.sei.cmu.edu!ajpo.sei.cmu.edu!goodsenj
  3. From: goodsenj@ajpo.sei.cmu.edu (John Goodsen)
  4. Subject: Re: MI - clutching at straws
  5. Message-ID: <1992Sep11.063338.2549@sei.cmu.edu>
  6. Sender: netnews@sei.cmu.edu (Netnews)
  7. Organization: Ada Joint Program Office
  8. References: <1992Sep5.065504.18997@sei.cmu.edu> <EACHUS.92Sep8135021@Dr_No.mitre.org>
  9. Date: Fri, 11 Sep 1992 06:33:38 GMT
  10. Lines: 74
  11.  
  12.  
  13. eachus@Dr_No.mitre.org (Robert I. Eachus) writes:
  14.  
  15. >
  16. >   >>A program which has objects which are simultanously in lists and trees,
  17. >   >>and uses MI to manage both structures is a mess.  Such a program can be
  18. >   >>created and made to work, but the list primitives will have to be aware
  19. >   >>of the tree primitives and vice-versa.
  20. >
  21. >   > It's not very persuading to point out a poor design and then state
  22. >   > that the technology was the fault.
  23. >
  24. >   I think you are agreeing with me, but the quote out of context
  25. >seems to say something I didn't intend...
  26. >
  27. >A design which contains objects which are simultaneously in lists
  28. >and trees is not inherently a bad design.  
  29.  
  30.  
  31. No, but your intent to insist that the 2 classes must be "aware"
  32. of each other is what I refer to.  Your arbitrary choice of a poor
  33. design example for MI does not invalidate the usefulness of MI.
  34.  
  35. >But if you need to do it,
  36. >the programmer needs either to develop a set of higher level
  37. >abstractions or pay attention to details when an object is say removed
  38. >from a list.  (If the object is also an interior node in the tree, do
  39. >you have to delete it from the tree first, or just remember its
  40. >children and reinsert them? Is it legal to have objects that are in a
  41. >list but not in a tree, or vice-versa? And so on.)  It can be done,
  42. >BUT if list and tree primitives are separately inherited the
  43. >programmer has to do most of the work.  A much better approach would
  44. >be to use single inheritance from a tree type, and extend it with list
  45. >primitives which are sensitive to the tree structure.  The progammer
  46. >must still answer the same questions, but only in one place--the
  47. >definition of the list type.
  48. >
  49.  
  50. There is no need to confuse the *insertion* of an object into
  51. multiple containers with multiple inheritance.  To argue this silly
  52. example is moot.  You need to come up with a valid MI example before
  53. you start knocking the usefulness of MI.  -- Bob Crispen -- where's that
  54. MI summary post ?
  55.  
  56. >
  57. >     So what I was really trying to say was that in this example it is
  58. >dificult to compare relative advantages and disadvantages of different
  59. >MI approaches, since any SI approach is so much cleaner.
  60.  
  61. I no way have you shown the SI approach to be much cleaner. Misleading
  62. statements like this are of no usefulness in the pursuit of the MI truth.
  63. To insist that inheritance only exist within single threads is somewhat
  64. fascist, IMHO.
  65.  
  66. Use a little Jeet Kun Do:  "Absorb what is useful, disregard what is not"
  67.  
  68. It is silly to say multiple inheritance is *never* useful.  Just as it is 
  69. silly to say single inheritance is *always* cleaner.  Neither statement is
  70. correct.  The correct answer is:  Use MI when it makes sense, use SI when
  71. it makes sense.  The 2 concepts are not contradictory.  
  72.  
  73. >--
  74. >
  75. >                                        Robert I. Eachus
  76. >
  77. >with STANDARD_DISCLAIMER;
  78.  
  79. 28~
  80. John Goodsen
  81. goodsenj@ajpo.sei.cmu.edu
  82. -- 
  83. John Goodsen                              Ada Joint Program Office
  84. jgg@evb.com                               PCIS Programme
  85. 800-877-1815                              goodsenj@ajpo.sei.cmu.edu
  86.