home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11620 < prev    next >
Encoding:
Text File  |  1992-07-27  |  4.3 KB  |  100 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!ads.com!saturn!doug
  3. From: doug@monet.ads.com (Doug Morgan)
  4. Subject: Re: Novice? question: Designing for multiple inheritance w/ templates
  5. In-Reply-To: mat@uunet.uu.net!mole-end's message of 25 Jul 92 06:55:23 GMT
  6. Message-ID: <DOUG.92Jul27113831@monet.ads.com>
  7. Sender: usenet@ads.com (USENET News)
  8. Organization: Advanced Decision Systems, Mountain View, CA 94043, +1 (415)
  9.     960-7300
  10. References: <1992Jul9.144630.10863@clpd.kodak.com>
  11.     <1992Jul23.175814.15356@ucc.su.OZ.AU>
  12.     <1992Jul25.065523.3855@uunet.uu.net!mole-end>
  13. Date: Mon, 27 Jul 1992 19:38:31 GMT
  14. Lines: 84
  15.  
  16. In article <1992Jul25.065523.3855@uunet.uu.net!mole-end> mat@uunet.uu.net!mole-end writes:
  17. >In article <1992Jul23.175814.15356@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  18. >> In article <1992Jul21.131054.20622@mole-end> mat@mole-end writes:
  19. > .
  20. >  .
  21. >   ....
  22. >>     When using mixins, the abstractions are derived, using
  23. >> MI, from each other. They're the "problem domain" stuff aren't they?
  24. >
  25. >No, the examples you give are especially solution-domain.  They come from
  26. >programming technology and express programming-type concepts applied to
  27. >programmed objects.
  28. >
  29. >Problem-domain stuff includes most of the examples in the popular OO
  30. >texts, things that are expressed as `is-a' or `is-a-kind-of-a,' e.g.
  31. >`A hardcover book is a kind of a book' (derive hardcover book from
  32. >book), `A salaried employee is a kind of employee,' (derive salaried
  33. >employee from employee), `A gravel road is a kind of road,' (derive
  34. >gravel road from road).
  35.  
  36. Multiple inheritance applies to all sorts of stuff, problem-domain and
  37. implementation.  Inheritance essentially means adding new constraints
  38. and extra behaviors (behaviors made reasonable because new constraints
  39. are now guaranteed to be satisfied).  Multiple inheritance essentially
  40. means taking the union of superclass constraints and behaviors (plus
  41. any extras thrown in directly at the inheritance step).
  42.  
  43. Here is a simple problem-domain example:
  44.  
  45.                    book
  46.                   /    \
  47.       hardcover-book  book-with-color-plates
  48.                   \    /
  49.       hardcover-book-with-color-plates
  50.  
  51. Or another:
  52.  
  53.                  employee
  54.                   /    \
  55.    salaried-employee  handicapped-employee
  56.                   \    /
  57.         handicapped-salaried-employee
  58.  
  59. Or: gravel-less-than-2%-grade-road.
  60.  
  61. Note that none of the above problem-domain intermediate classes look
  62. like (what I think most people would immediately call) a mixin.  They
  63. all diamond back up to a common and fairly complicated class.  This
  64. may be the root of issue in this thread.  Implementation-domain MI
  65. often appears more mixin-like with multiple roots or with common roots
  66. near the top of the class hierarchy.  Implementation-domain stuff
  67. manipulates a hunk of memory and associated procedures.  In C++ no
  68. class represents this concept, so implementation-domain MI could
  69. easily have multiple roots.  In most other OO languages, some class
  70. represents the high-level implementation aspects of all other classes
  71. and implementation-domain mixins might inherit from that.  Another
  72. view of the same argument: it wouldn't make much sense to make a
  73. generic-thing-with-color-plates mixin.  Restricting the class to the
  74. domain of books gives the class meaning.  So, problem-domain mixins
  75. may tend to inherit from problem-domain classes rather than forming a
  76. new root or inheriting strictly from a top-level class of the the
  77. language.
  78.  
  79. >Is it possible to program with mixins for the problem domain?  Yes, it is.
  80. >Is the result malleable?  I suspect not.  I haven't examined any large
  81. >model built that way, so I'm not sure.  I rather suspect that some of the
  82. >inheritance links that get built that way should be `part-of' links
  83. >(bi-directional `has-a' links between objects collaborating to implement
  84. >the functionality of the object representing the `whole').
  85.  
  86. Given good language support, MI and mixins are expressive and
  87. malleable.  Given C++, your other implementation options might well be
  88. worth exploring.
  89.  
  90. >-- 
  91. > (This man's opinions are his own.)
  92. > From mole-end                Mark Terribile
  93. >
  94. > uunet!mole-end!mat, Somewhere in Matawan, NJ
  95.  
  96. ------------------------------------------------------------
  97. Doug Morgan, doug@ads.com, (415) 960-7300
  98. Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.)
  99. 1500 Plymouth St., Mountain View, CA 94043-1230
  100.