🚀 go-pugleaf

In article: <401gnk$mk0@metro.ucc.su.OZ.AU>  maxtal@Physics.usyd.edu.au (John Max Skaller) writes:
> 	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.
> 

I am not sure I completely agree with you.  I could argue that the
following hierarchy is a reasonably sensible approach.

    class Person
    {
         char* name;
         ....
    };

    class Employee 
        : public virtual Person
    {
        int employee_number;
        ....
    };

    class Golfer
        : public virtual Person
    {
        int handicap;
        ....
    };

    class Company_Golf_Club_Member
        : public Employee, public Golfer
    {
        int rank;
        ....
    };

Here we have the situation where a Golfer IS A Person.  An Employee 
IS A Person.  And a Company_Golf_Club_Member IS both A Golfer, and 
AN Employee !!

N.B. An Employee need not be a Golfer and visa-versa.

This to me would seem to be a natural mechanism to represent the 
class hierarchy identified above.  However the C++ virtual base class 
mechanism causes the above implementation to take on a number of 
warts, especially in the use of non-default constructors.

Taking this case in point, a Person must always have a name, date of 
birth etc., and so to provide a default constructor for such a class 
is meaningless!  These warts generally lead one away from developing 
hierarchies that utilise virtual inheritance and hence cause one to 
pervert the class hierarchy instead!!

While the above example is possibly not the best illustration, (I am 
sure many readers of this newsgroup could come up with a hierarchy 
that does not involve virtual inheritance), it does however show my 
point.

My original posting at the start of this thread requested the reasons 
*why* non-default virtual base class constructors required calling 
from the most derived class, rather than the lowest class where all 
the virtual class instances had been inherited.  So far *no* 
responses to this thread have addressed this question.  I am sure 
there are good technical reasons for this, and I could possibly make 
a reasonable guess.  However, I would like to know the reason(s) from 
the horse's mouth so to speak.

For example if we were to add the following to the above hierarchy:

    class Club_Captain
        : public Company_Golf_Club_Member
    {
        int years_as_captain;
        ....
    }

Why does the class Club_Captain need to call Person's constructor 
directly, rather than letting the constructor of 
Company_Colf_Club_Member sort it out?  This would seem to be a much 
better approach (from the software authors point of view).

Bryan.
-- 
Bryan Drew,                              Email: bdrew@hi-q.demon.co.uk
Hi-Q Systems Limited,                    Tel  : +44 (0)1252-815035
Hi-Q House, Ancells Court,               Fax  : +44 (0)1252-815022
Fleet, Hants GU13 8UZ UK