🚀 go-pugleaf

>>> On 2 Nov 1995 21:15:51 GMT,
>>> mbk@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN (Matthew
>>> B. Kennel) said:

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

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

Matthew> Is this always so? 

No, it depends on how you define inheritance. But it covers the most
common definitions of inheritance (nee` prefixing), both single and
multiple, and so on (is-a, has-a, more or less).

Matthew> In Sather one may inherit implementation, and delete some
Matthew> attributes or functions from the class being inherited.

This is not quite like inheritance as in prefixing: it is a welcome step
towards a more general reuse algebra, one that allows a-la-carte reuse
of interface and implementation components.

Matthew> And there is the type SAME (the class of the new object being
Matthew> defined), which is re-interpreted in the context of the new
Matthew> class, even in implementation inherited from the supplying
Matthew> class.

Well, this is more like (parametric) genericity than inheritance. Indeed
if one had parametric genericity with my modest proposal :-) this would
be cleaner.


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

The problem is that "inheritance" has become a good-for-all term for all
sorts of reuse. This is no good: reuse of interface is one thing, reuse
of implementation is another, hierarchical reuse is not the same as
piecemeal reuse, genericity is not the same as "inclusion polymorphism".

The main goal of my original point is to show that inheritance, as
commonly understood (prefixing) is a pointless trick, for composition
can do the same job. Other concepts, like a more general algebra for
reuse, should be orthogonal and available as well.

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

But then consider the beauty of "any unique subset": if there is
conflict or ambiguity one can always resolve it by specifying a fuller,
less ambiguous name. C++ tries to do something like this with the

	object.CLASS::member

notation, which gives away the whole show...

Matthew> I don't know if this is desirable.  I think it could make
Matthew> things quite nonobvious ('now where on earth is this function?
Matthew> It's not in the class') and tricky.

This is a much bigger problem in conventional inheritance, after all
Eiffel and Smalltalk have "flattening" tools for some reason...