🚀 go-pugleaf

Piercarlo Grandi (pcg@aber.ac.uk) wrote:

: With a minuscule little rule taken from PL/1 and Cobol (that any member
: of a structure can be named with any unique subset of its full dotted
: name) inheritance can simply disappear, folded back into composition,
: with no loss, and lots of gain (in other words, delegation rules the
: classes! :->).

:   Example:

: 	struct A { ... a ... f() }
: 	struct B { ... b ... g() }
: 	struct C { ... A x ... B y ... c ... g() ... }

: 	struct C z;
: 	assert (&z.a == &z.A.a);
: 	assert (&z.g == &z.B.g);

Is this always so? 

In Sather one may inherit implementation, and delete some attributes or
functions from the class being inherited.  And there is the type SAME (the
class of the new object being defined), which is re-interpreted in the
context of the new class, even in implementation inherited from the
supplying class. 

Eiffel no doubt has similar issues. 

There is no notion of "the A part of C" or the "B part of C" as
above when C inherits from A. 

So this kind of inheritance cannot be simulated with composition.  I
like this kind of inheritance.

You can advocate a rule about such structures if you should desire,
(but distinct from inheritance):  The signatures of included attributes
(like variables typed A and B above) are implicitly included
into the "main class" as long as there is no name conflict or
ambiguity. 

I don't know if this is desirable.  I think it could make things
quite nonobvious ('now where on earth is this function? It's not
in the class') and tricky.   Perhaps one ought only automatically
delegate routines for attrbutes designated with a distinct keyword. 

cheers
Matt