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

  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
  3. From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
  4. Subject: Re: Novice? question: Designing for multiple inheritance w/ templates
  5. Message-ID: <1992Jul23.175814.15356@ucc.su.OZ.AU>
  6. Sender: news@ucc.su.OZ.AU
  7. Nntp-Posting-Host: extro.ucc.su.oz.au
  8. Organization: MAXTAL P/L C/- University Computing Centre, Sydney
  9. References: <1992Jul9.144630.10863@clpd.kodak.com> <1992Jul20.152931.8037@ucc.su.OZ.AU> <1992Jul21.131054.20622@mole-end>
  10. Date: Thu, 23 Jul 1992 17:58:14 GMT
  11. Lines: 76
  12.  
  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. >>     A golden rule is : ALL ABSTRACT BASES SHOULD BE INHERITED
  26. >> PUBLIC VIRTUAL.
  27. >>     IMHO almost every public derivation ought to be virtual.
  28. >> Public virtual derivation with abstract classes is used to
  29. >> make a multi-faceted abstraction.
  30. >>     Because the derivation is virtual, you can hook in implementations
  31. >> of the various abstractions of combinations of them at the last minute:
  32. >> late binding of implementation details.  These details [should] usually
  33. >> be bound in to a class with local scope (or file scope) ... guaranteeing
  34. >> all access is dependent on the abstract properties of the object only.
  35. >>     This mechanism ... and guarrantees the run-time type of the object
  36. >> can ONLY be be accessed via declared virtual functions.
  37. >  ...
  38. >>     A new optimisation technique (like caching) can be
  39. >> hooked in, on an object by object basis, at construction time.
  40. >
  41. >This is exactly what I was saying.  The thing added by Virtual MI is added
  42. >not for the sake of what the class represents, but for the sake of the
  43. >class representation.  It doesn't represent something in the problem
  44. >domain and won't appear on an object-occurrence or class-relationship
  45. >diagram.  Instead it provides something that belongs to the solution domain,
  46. >to the properties of the programmatic object rather than the analysis
  47. >object.
  48. >
  49. >Or do I misunderstand you completely?
  50.  
  51.     Maybe I misunderstand. 
  52.  
  53.     IMHO: ALMOST ALL derivation should be public, and ALMOST ALL
  54. public derivation should be virtual. Inheritance of an abstract
  55. base class should be virtual and public even more often than almost
  56. all :-).
  57.  
  58.     When using mixins, the abstractions are derived, using
  59. MI, from each other. They're the "problem domain" stuff aren't they?
  60. They MUST use virtual to share abstract bases, and concepts cannot
  61. sensibly be repeated: virtual is mandatory for 'is-a' relations.
  62.  
  63.     Even the non-shared bases must be virtual in the abstraction
  64. DAG because otherwise you can't hook in the implementation classes,
  65. they must be derived using virtual from the abstractions to 
  66. ensure they hook in to the right place using the 'sibling call'
  67. mechanism.
  68.  
  69.     The only times I can think of that inheritance should
  70. not be virtual, then it should also be private: and those cases
  71. are precisely the implementation representation type uses
  72. of inheritance ("solution domain").
  73.  
  74.     So I think it is the opposite of what you say,
  75. although perhaps I misunderstand.
  76.  
  77. >-- 
  78. > (This man's opinions are his own.)
  79. > From mole-end                Mark Terribile
  80. >
  81. > uunet!mole-end!mat, Somewhere in Matawan, NJ
  82.  
  83.  
  84. -- 
  85. ;----------------------------------------------------------------------
  86.         JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
  87.     Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
  88. ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
  89.