🚀 go-pugleaf

In article <3up5ne$4gv@fsgm01.fnal.gov>,
David Sachs <sachs@fnal.fnal.gov> wrote:
>maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
>
>>In article <3u6mnq$bag@fsgm01.fnal.gov>,
>>David Sachs <sachs@fnal.fnal.gov> wrote:
>>>
>>>I am annoyed that the standards committee waffled badly on handling
>>>the default version of operator=. The proposed standard specifically
>>>states, that the number of times a virtual base is copied can be
>>>implmentation dependent.
>
>>	I agree. It's pretty bad.  However, a virtual base
>>shouldn't have any user data in it anyhow.
>
>I do feel that a virtual base should normally be initialized via its
>default constructor. This does NOT mean that it should have no data 
>whatsoever.

	If you examine several other problems, however you will
probably come to that conclusion as a rule of thumb as I have.

	For example how do you do assignments in the presence of
virtual bases? What stops the data of the virtual base being assigned
more than once?

	More theoretically -- virtual bases have a property of
uniqueness which allows them to represent the type of their class.
This is exactly what you need to construct a SET of types whose
intersection is that which a derived class can be said to _BE_ a subtype.
This kind of relationship strongly suggests it ought to be 
an relationship between semantic interfaces -- NOT representations.

	Categorically, this is a PRODUCT of interfaces.
	(And a SUM of data)

	On the other hand non-virtual bases containing data are
NOT unique (and it's a bug in the language you can't name them,
not even by a path-name). Inheritance here is little more than
composition with forwarding functions.

	Categorically, this is a SUM of interfaces.
	(And a product of data)

	Categorically, sums and products are DUAL notions.
	Interfaces and representations are also dual.

	Another example: a struct is a PRODUCT. (Cartesian!).
A discriminated union is a SUM.

	The structure of these things is the same if you reverse
all your concepts (that's what 'dual' means).

	What does all this mean? Obviously, interesecting
interfaces is what virtual bases are good at -- but 
if two virtual bases both have a common virtual base,
what does it mean if there are representations?

	It cannot work! You have to waste the data and provide
a unifying representation!

	FOR EXAMPLE:

	struct Complex { float x,y; .. }
	struct Real : virtual Complex { ?????? }

Why waste the 'y' value which is always 0 in a Real number?
Now consider the interface instead of the representation:

	struct Complex { 
			virtual float x()const=0; 
			virtual float y()const=0; .. }
	struct Real : virtual Complex { 
		float y()const { return 0.0; } ... 

This works, it supports polymorphism and subtyping correctly.
Supplying data does NOT.

The best way to do this is to use mixins, which Barton and
Nackman speak of as separating the interface from the implementation.

Doing this allows "isA" to be a relationship expressed 
by virtual inheritance between abstract
classes to build up concepts independently of representation.
Representation independence is the key to polymorphism and 
transparent optimisation of tested software without 
risking its correctness in more than a highly localised place.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
	Maxtal Pty Ltd,		    
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21 
        NSW 2037, AUSTRALIA	    Phone: 61-2-566-2189