Xref: utzoo comp.lang.c++:6450 comp.object:928
Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg
From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.lang.c++,comp.object
Subject: Re: Inheritance vs. Composition
Summary: Inheritance *is* composition + syntactic sugar - clarity
Message-ID: <PCG.90Feb13153607@rupert.cs.aber.ac.uk>
Date: 13 Feb 90 15:36:07 GMT
References: <CIMSHOP!DAVIDM.90Feb11005056@uunet.UU.NET> <10465@alice.UUCP>
Sender: pcg@aber-cs.UUCP
Organization: Coleg Prifysgol Cymru
Lines: 83
In-reply-to: ark@alice.UUCP's message of 11 Feb 90 16:38:25 GMT

In article <10465@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:

   In article <CIMSHOP!DAVIDM.90Feb11005056@uunet.UU.NET>,
   cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:

   > I'm curious as to the reasons that one might use inheritance (derivation of a
   > new object from the definition of an old object) and the reasons that one
   > might use composition (wrapping multiple objects in another object).

   The key difference in C++ is that if class D inherits [publicly] from
   class B, then you can pass a D argument to any function that takes
   a B parameter.  Another way of looking at it is that if you derive
   D from B, then a D object does [at least] everything a B object does.
   If you define a class D with a B member, then you must define every
   operation you want a D to be able to perform, even if that is replicating
   many of the B operations.

But this is just syntactic sugaring. And it leads to a lot of problems
as well, like all the funny rules about multiple inheritance, and the
ambiguity between inheritance as is-a and as part-of, and so on.

The inheritance issue is bogus and clouds the real problem, that
in sufficiently sophisticated applications you have a data
modeling and design problem of the same size and complexity as
that of a data base, and you need to apply the same conceptual
tools, and map the concepts onto ultimately contiguity or
pointers (the only ways we have in a computer to indicate a
relationship between data).

Just think that inheritance could be entirely obviated if one were
allowed to use composition with nameless members, or if a member could
be identified by any unambiguous path to it, like in PL/1.

Example:

	class vehicle { ... int weight, speed, cost; ... }	v0;
	class car : vehicle { ... int seats; ... }		c0;
	class truck : vehicle { ... int load; ... }		t0;

vs. (assuming you have unnamed members):

	class vehicle { ... int weight, speed, cost; ... }	v1;
	class car { ... vehicle; int seats; ... }		c1;
	class truck { ... vehicle; int load; ... }		t1;

or (assuming memberscan be named by any unambiguous way):

	class vehicle { ... int weight, speed, cost; ... }	v2;
	class car { ... vehicle v; int seats; ... }		c2;
	class truck { ... vehicle v; int load; ... }		t2;

You can write 'c0.speed' or 'c1.weight' or 't2.cost'
indifferently; the same goes of course for function members
(which should be abolished as well, by the way, by allowing any
function whose first argument is of a class type to be invoked in
infix position).

Getting rid of inheritance, and using only composition with some
sugaring to make members of members visible at the outer level, is
entirely possible.

	You also need a few paraphernalia, like sensible casts
	between	(pointer to a member)/(to the enclosing structure)
	and viceversa, and sensible member pointers.

It is desirable on two grounds: that inheritance is redundant, and it
clouds serious discussions about the many problems of data modeling
using composition.

	I strongly believe that inheritance was invented *only* because
	in Simula 67 class objects could only be accessed via references,
	and 'prefixing' (as it was more correctly called) was needed as
	an efficient way of concantenating object representations. The
	essentially linear nature of prefixing is what causes all the
	conceptual and implementation problems with MI.

	Notice also that in some cases MI has actually to be implemented
	using references in C++. Doesn't this point to a fundamental
	problem with the concept? :-(.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk