home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
- From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
- Subject: Re: Novice? question: Designing for multiple inheritance w/ templates
- Message-ID: <1992Jul23.175814.15356@ucc.su.OZ.AU>
- Sender: news@ucc.su.OZ.AU
- Nntp-Posting-Host: extro.ucc.su.oz.au
- Organization: MAXTAL P/L C/- University Computing Centre, Sydney
- References: <1992Jul9.144630.10863@clpd.kodak.com> <1992Jul20.152931.8037@ucc.su.OZ.AU> <1992Jul21.131054.20622@mole-end>
- Date: Thu, 23 Jul 1992 17:58:14 GMT
- Lines: 76
-
- In article <1992Jul21.131054.20622@mole-end> mat@mole-end writes:
- >In article <1992Jul20.152931.8037@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
- >> In article <1992Jul19.233851.15525@mole-end> mat@mole-end writes:
- >>
- >> >... From what I can tell, virtual inheritance is principally useful
- >> >for importing what might be called `object representation behavior,'
- >> >e.g. printability, special allocation and deallocation, etc.--things
- >> >that are related to the representation OF the object, rather than to
- >> >what the object itself represents.
- >
- >> Quite the opposite I find. Its prinicple use is in
- >> deriving new abstractions from old.
- >> A golden rule is : ALL ABSTRACT BASES SHOULD BE INHERITED
- >> PUBLIC VIRTUAL.
- >> IMHO almost every public derivation ought to be virtual.
- >> Public virtual derivation with abstract classes is used to
- >> make a multi-faceted abstraction.
- >> Because the derivation is virtual, you can hook in implementations
- >> of the various abstractions of combinations of them at the last minute:
- >> late binding of implementation details. These details [should] usually
- >> be bound in to a class with local scope (or file scope) ... guaranteeing
- >> all access is dependent on the abstract properties of the object only.
- >> This mechanism ... and guarrantees the run-time type of the object
- >> can ONLY be be accessed via declared virtual functions.
- > ...
- >> A new optimisation technique (like caching) can be
- >> hooked in, on an object by object basis, at construction time.
- >
- >This is exactly what I was saying. The thing added by Virtual MI is added
- >not for the sake of what the class represents, but for the sake of the
- >class representation. It doesn't represent something in the problem
- >domain and won't appear on an object-occurrence or class-relationship
- >diagram. Instead it provides something that belongs to the solution domain,
- >to the properties of the programmatic object rather than the analysis
- >object.
- >
- >Or do I misunderstand you completely?
-
- Maybe I misunderstand.
-
- IMHO: ALMOST ALL derivation should be public, and ALMOST ALL
- public derivation should be virtual. Inheritance of an abstract
- base class should be virtual and public even more often than almost
- all :-).
-
- When using mixins, the abstractions are derived, using
- MI, from each other. They're the "problem domain" stuff aren't they?
- They MUST use virtual to share abstract bases, and concepts cannot
- sensibly be repeated: virtual is mandatory for 'is-a' relations.
-
- Even the non-shared bases must be virtual in the abstraction
- DAG because otherwise you can't hook in the implementation classes,
- they must be derived using virtual from the abstractions to
- ensure they hook in to the right place using the 'sibling call'
- mechanism.
-
- The only times I can think of that inheritance should
- not be virtual, then it should also be private: and those cases
- are precisely the implementation representation type uses
- of inheritance ("solution domain").
-
- So I think it is the opposite of what you say,
- although perhaps I misunderstand.
-
- >--
- > (This man's opinions are his own.)
- > From mole-end Mark Terribile
- >
- > uunet!mole-end!mat, Somewhere in Matawan, NJ
-
-
- --
- ;----------------------------------------------------------------------
- JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au
- Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
- ;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
-