home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / modula3 / 844 < prev    next >
Encoding:
Text File  |  1992-07-23  |  3.0 KB  |  65 lines
  1. Newsgroups: comp.lang.modula3
  2. Path: sparky!uunet!mcsun!Germany.EU.net!Urmel.Informatik.RWTH-Aachen.DE!schumann!pk
  3. From: pk@rwthi3.informatik.rwth-aachen.de (Peter Klein)
  4. Subject: Re: Proposed langauge changes / MI
  5. Message-ID: <1992Jul23.122324.5310@Urmel.Informatik.RWTH-Aachen.DE>
  6. Sender: news@Urmel.Informatik.RWTH-Aachen.DE (Newsfiles Owner)
  7. Nntp-Posting-Host: schumann
  8. Reply-To: pk@rwthi3.informatik.rwth-aachen.de
  9. Organization: Lehrstuhl fuer Informatik III, RWTH Aachen, Germany
  10. References: <MOSS.92Jul18115425@ibis.cs.umass.edu>
  11. Date: Thu, 23 Jul 92 12:23:24 GMT
  12. Lines: 51
  13.  
  14. In article 92Jul18115425@ibis.cs.umass.edu, moss@cs.umass.edu (Eliot Moss) writes:
  15. >Peter suggests that if D inherits from B and C, then B and C must share a
  16. >common ancestor A. This condition is trivially satisfied - ROOT is the
  17. >anscestor of all OBJECT types. Peter, I think perhaps you have a different and
  18. >stronger condition in mind. Could you try to articulate it? I don't think
  19. >requiring B and C to have the same immediate ancestor is general enough, and I
  20. >think saying they have to have a common ancestor other than ROOT requires more
  21. >defense -- MI ought to allow one to combine completely orthogonal types if
  22. >that's useful, shouldn't it? Why is it wrong to do so? You seem to have a
  23. >style or idiom in mind that I have not been able to derive from what you've
  24. >said so far ....
  25. >--
  26. >
  27. >        J. Eliot B. Moss, Associate Professor
  28. >        Department of Computer Science
  29. >        Lederle Graduate Research Center
  30. >        University of Massachusetts
  31. >        Amherst, MA  01003
  32. >        (413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
  33.  
  34. Excuse me for being unclear. (I obviously haven't had my best day when I wrote
  35. that article anyway :).
  36.  
  37. Well, although you're questions seem to be a little bit rhetorical: yes, I
  38. actually meant *direct* subclasses. To put it in other words: I would agree
  39. to MI if it is restricted to very simple fork/join situations. Furthermore,
  40. I think that all data from the common superclass should be shared.
  41.  
  42. If you want to combine orthogonal classes, you actually build the cartesian
  43. product of these classes. If I'm not completely wrong, this is exactly what
  44. RECORDs are good for. So, if B and C are independent, I would combine these
  45. using A = OBJECT b: B; c: C; END.
  46.  
  47. I'm totally aware of the fact that this is a little bit awkward for the people
  48. used to MI from other languages, because you have to copy and merge B and C's
  49. interfaces to get an interface for A. But it *can* be done. On the other hand,
  50. if you have a (virtual in the C++ sense) superclass D and subclasses B and C
  51. from D, there is no way to simulate A = B, C OBJECT END with SI without loosing
  52. data hiding.
  53.  
  54. So, my proposal is sort of a compromise. It prevents MI from getting too
  55. complicated - for the user as well as for the compiler/run time system. But I
  56. don't think it prohibits the essential point about MI.
  57. ---
  58. Peter Klein                        E-Mail: pk@rwthi3.informatik.rwth-aachen.de
  59. Lehrstuhl fuer Informatik III      Tel.: +49/241/80-21320
  60. Ahornstrasse 55                    Fax.: +49/241/80-21329
  61. RWTH Aachen
  62. D-5100 Aachen
  63. Germany
  64.  
  65.