🚀 go-pugleaf

Piercarlo Grandi (pcg@aber.ac.uk) wrote:
: >>> 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).

OK.  However, I think doing this would needlessly limit 'inheritance';
already Eiffel and Sather need something more. 

: 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.

Yes.  Parametric genericity is nice too. I guess you can think of
it like there's just always a pre-defined SAME parameter for all classes.

: 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".

Yes indeed.  Sather people don't like to use the term "inheritance" among
ourselves.   The language has 

*  subtyping:  assertion that a given class conforms to a certain
	       abstract protocol, and thus is a permissible run-time
	       instantiation for variables declared with the
	       abstract type.

*  implementation inclusion:  A shorthand for 're-typing in' implementation,
	       It collects common implementation into one "class". 

: 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...

OK.  But what happens when "what is a unique subset" in the code
of one implementation is no longer unique when it is combined with
additional code?

Eiffel and Sather have renaming rules upon implementation inclusion
for this reason.

: 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...

True. 

But what would it mean "to conform to a given signature" (i mean
a collection of routine signatures) then?

It seems that denoting "special data thingys used for composition" is a
shorthand for "including all the implementation and datastorage that goes
along with that object". 

Personally I would like something with a little more individual control
(e.g. Eiffel and Sather) which might let you pick and choose just what
things you want to keep and the ones you want to junk.