home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11518 < prev    next >
Encoding:
Text File  |  1992-07-25  |  3.1 KB  |  71 lines

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@uunet.uu.net!mole-end
  4. Subject: Re: Novice? question: Designing for multiple inheritance w/ templates
  5. Message-ID: <1992Jul25.065523.3855@uunet.uu.net!mole-end>
  6. Summary: Problem Domain/Solution Domain
  7. Organization: :
  8. References: <1992Jul9.144630.10863@clpd.kodak.com> <1992Jul23.175814.15356@ucc.su.OZ.AU>
  9. Date: Sat, 25 Jul 1992 06:55:23 GMT
  10. Lines: 59
  11.  
  12. In article <1992Jul23.175814.15356@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  13. > In article <1992Jul21.131054.20622@mole-end> mat@mole-end writes:
  14. > >In article <1992Jul20.152931.8037@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
  15. > >> In article <1992Jul19.233851.15525@mole-end> mat@mole-end writes:
  16. > >> 
  17. > >> >...  From what I can tell, virtual inheritance is principally useful
  18. > >> >for importing what might be called `object representation behavior,'
  19. > >> >e.g. printability, special allocation and deallocation, etc.--things
  20. > >> >that are related to the representation OF the object, rather than to
  21. > >> >what the object itself represents.
  22.  
  23. > >>     Quite the opposite I find. Its prinicple use is in 
  24. > >> deriving new abstractions from old. 
  25. > >> ...
  26.  
  27. > >>     A new optimisation technique (like caching) can be
  28. > >> hooked in, on an object by object basis, at construction time.
  29.  
  30. > >This is exactly what I was saying.  The thing added by Virtual MI is added
  31. > >not for the sake of what the class represents, but for the sake of the
  32. > >class representation.  ...
  33.  
  34. > >Or do I misunderstand you completely?
  35.  
  36. >     Maybe I misunderstand. 
  37.  
  38. >     IMHO: ALMOST ALL derivation should be public, and ALMOST ALL
  39. > public derivation should be virtual. Inheritance of an abstract
  40. > base class should be virtual and public even more often than almost
  41. > all :-).
  42.  
  43. >     When using mixins, the abstractions are derived, using
  44. > MI, from each other. They're the "problem domain" stuff aren't they?
  45.  
  46. No, the examples you give are especially solution-domain.  They come from
  47. programming technology and express programming-type concepts applied to
  48. programmed objects.
  49.  
  50. Problem-domain stuff includes most of the examples in the popular OO
  51. texts, things that are expressed as `is-a' or `is-a-kind-of-a,' e.g.
  52. `A hardcover book is a kind of a book' (derive hardcover book from
  53. book), `A salaried employee is a kind of employee,' (derive salaried
  54. employee from employee), `A gravel road is a kind of road,' (derive
  55. gravel road from road).
  56.  
  57. Is it possible to program with mixins for the problem domain?  Yes, it is.
  58. Is the result malleable?  I suspect not.  I haven't examined any large
  59. model built that way, so I'm not sure.  I rather suspect that some of the
  60. inheritance links that get built that way should be `part-of' links
  61. (bi-directional `has-a' links between objects collaborating to implement
  62. the functionality of the object representing the `whole').
  63.  
  64. This is drifting off into abstract talk; we are better off with examples
  65. and with class-relationship or object-relationship diagrams before us.
  66. -- 
  67.  (This man's opinions are his own.)
  68.  From mole-end                Mark Terribile
  69.  
  70.  uunet!mole-end!mat, Somewhere in Matawan, NJ
  71.