home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / ada / 2491 < prev    next >
Encoding:
Text File  |  1992-08-31  |  4.8 KB  |  100 lines

  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!zrz.tu-berlin.de!math.fu-berlin.de!Sirius.dfn.de!Urmel.Informatik.RWTH-Aachen.DE!wagner!pk
  3. From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
  4. Subject: Re: MI - clutching at straws
  5. Message-ID: <1992Aug31.153641.29954@Urmel.Informatik.RWTH-Aachen.DE>
  6. Sender: news@Urmel.Informatik.RWTH-Aachen.DE (Newsfiles Owner)
  7. Nntp-Posting-Host: wagner
  8. Reply-To: pk@rwthi3.informatik.rwth-aachen.de
  9. Organization: Lehrstuhl fuer Informatik III, RWTH Aachen, Germany
  10. References: <EACHUS.92Aug23173050@Dr_No.mitre.org>
  11. Date: Mon, 31 Aug 92 15:36:41 GMT
  12. Lines: 86
  13.  
  14. In article 92Aug23173050@Dr_No.mitre.org, eachus@Dr_No.mitre.org (Robert I. Eachus) writes:
  15. >In article <1992Aug23.171350.27117@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.informatik.rwth-aachen.de (Peter Klein) writes:
  16. >
  17. >   Consider the following example: I start with an abstract data type
  18. >   for a graph.  Now I augment the basic type in several independant
  19. >   ways, let's say to make attributed, node- and edge-labeled graphs.
  20. >   Finally, I would like to have some special graphs, e.g. abstract
  21. >   syntax graphs or binary trees, which combine one or more of the
  22. >   above extensions. How can I express this without violating the
  23. >   abstractness of the involved data types? Maybe somebody's got some
  24. >   clever answer. Otherwise, I will keep thinking that MI is sometimes
  25. >   appropriate.
  26. >
  27. >   Okay, challenge accepted...
  28. >
  29. >   First, let's create the basic graph package.  The "normal" way to
  30. >do this in Ada is to use a model where different graphs are different
  31. >instances of a generic package, but other models are possible.  So
  32. >lets use a generic which exports an abstract type...
  33. >
  34. > [ ... some ada syntax deleted ... ]
  35. >
  36. >    In any case now most of the augmentations are natural and done by
  37. >different instantiations.  The special graphs, such as binary trees,
  38. >would be done by instantiating the GRAPHS package then adding
  39. >additional operations at a higher level.  In Ada 9X this can be done
  40. >by writing a binary tree generic which takes an instantiation of
  41. >GRAPHS as a parameter.  In Ada 83, you can do the same sort of thing,
  42. >but the declaration gets much messier.  (All of the visible types and
  43. >operations of the GRAPHS package must be passed as individual generic
  44. >parameters.)
  45. >
  46. >    Now it is possible to decorate a single GRAPHS instance with all
  47. >of the various special graph add ons.  In general, many of the
  48. >combinations wouldn't make sense, but that is an issue (in Ada) for
  49. >the programmer not the compiler.
  50. >
  51. >    I could ring a lot of changes on the theme, but in general, the
  52. >lesson is that, IN ADA, anything that might possibly be done with
  53. >multiple inheritance is probably better done with generics.  Notice
  54. >that in this example, I went out of my way to make single inheritance
  55. >possible.  A pure generic solution seems much more appropriate.  This
  56. >says nothing about whether or not MI is useful in other languages,
  57. >just that there is no reason to add it to Ada.
  58.  
  59. Well, I'm not overly surprised by this answer. In fact, when I posted
  60. the same example to the Modula-3 discussion, a similar solution was
  61. proposed. But this will not do.
  62.  
  63. It is important to keep in mind that genericity and inheritance are
  64. orthogonal concepts (see Betrand Meyer's "Genericity versus Inheritance,
  65. Journal of Pascal, Ada, & Modula-2, Vol. 7, No. 2, pp. 13-30,
  66. Wiley 1988 on this). In restricted cases, one can be simulated by
  67. the other. But this is pointless when we talk about the usefulness
  68. of the concepts as such.
  69.  
  70. What actually is lost when simulating inheritance with genericity
  71. is polymorphism. In your example, the implementation of the extensions
  72. is hidden from the base type. But the implementation of the basic
  73. type reveals *which* extensions are planned. This has some severe
  74. disadvantages:
  75.   -  No new extensions to the base type can be made without modifying
  76.      the base type.
  77.   -  Every client of the basic type *must* provide implementations for
  78.      the extensions, even if he doesn't need them.
  79. So, in OO terminology, you violate the open/closed principle for data
  80. abstraction using classes.
  81.  
  82. In a more general sense, it cannot be reasonable to extend a basic type
  83. by inheritance or by genericity depending on the fact whether you want
  84. to combine some extensions later on. If you think that the extensions
  85. should be done by inheritance, you'll end up missing MI if you want to
  86. combine extensions on a higher level. On the other hand, if you say that
  87. the extensions should be done using genericity, you won't need MI. But
  88. in this case, you don't need inheritance at all.
  89.  
  90. Peter
  91.  
  92. ---
  93. Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
  94. Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
  95. Ahornstrasse 55                    Fax.: +49/241/80-21329
  96. RWTH Aachen
  97. D-5100 Aachen
  98. Germany
  99.  
  100.