From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Novice? question: Designing for multiple inheritance w/ templates
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Thu, 23 Jul 1992 17:58:14 GMT

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 ------------------
Newsgroups: comp.lang.c++,comp.sys.hp