home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / ada / 2409 next >
Encoding:
Text File  |  1992-08-23  |  2.4 KB  |  51 lines
  1. Newsgroups: comp.lang.ada
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!Sirius.dfn.de!Urmel.Informatik.RWTH-Aachen.DE!smetana!pk
  3. From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
  4. Subject: MI - clutching at straws
  5. Message-ID: <1992Aug23.171350.27117@Urmel.Informatik.RWTH-Aachen.DE>
  6. Sender: news@Urmel.Informatik.RWTH-Aachen.DE (Newsfiles Owner)
  7. Nntp-Posting-Host: smetana
  8. Reply-To: pk@rwthi3.informatik.rwth-aachen.de
  9. Organization: Lehrstuhl fuer Informatik III, RWTH Aachen, Germany
  10. Date: Sun, 23 Aug 92 17:13:50 GMT
  11. Lines: 38
  12.  
  13. Some time ago, I started a thread in comp.lang.modula3 about the non/sense
  14. of MI (Modula-3 has SI only). Although most responses were pretty anti-MI,
  15. some examples were supplied for which no satisfying alternatives were given.
  16. Since I am unsure yet whether I find MI neccessary, I try again here.
  17.  
  18. To begin with, I don't think that *if* MI is useful, this use will be constrained
  19. to certain application areas. Just like SI, genericity and arrays, MI gives the
  20. programmer the opportunity to express a data design decision in a specific
  21. implementation language. So, either it is sensible as such or it is not.
  22.  
  23. Exactly for this reason I wonder why you exclude academic implementations from
  24. your considerations. A whole lot of good software is written in universities,
  25. for very different application areas. Even more, I believe that the percentage
  26. of people who actually experienced MI is higher in the academic field.
  27.  
  28. Well, I am convinced that MI is not neccessary for combining orthogonal classes.
  29. This is what records are for. But problems arise if several subclasses of a
  30. common superclass are combined into a MI subclass with the superclass fields
  31. shared.
  32.  
  33. Consider the following example: I start with an abstract data type for a graph.
  34. Now I augment the basic type in several independant ways, let's say to make
  35. attributed, node- and edge-labeled graphs. Finally, I would like to have
  36. some special graphs, e.g. abstract syntax graphs or binary trees, which
  37. combine one or more of the above extensions. How can I express this without
  38. violating the abstractness of the involved data types? Maybe somebody's got
  39. some clever answer. Otherwise, I will keep thinking that MI is sometimes
  40. appropriate.
  41.  
  42. Peter
  43. ---
  44. Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
  45. Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
  46. Ahornstrasse 55                    Fax.: +49/241/80-21329
  47. RWTH Aachen
  48. D-5100 Aachen
  49. Germany
  50.  
  51.