Re: viewpoints and multiple inheritance.
Frank Farance writes:
> Multiple inheritance sounds great from a "conceptual" perspective.
> Unfortunately, it runs into problems as soon as its used for hardened
> semantics. The C++ standards committee discovered that multiple inheritance
> was a bad idea. Here's a simple illustration of the problem:
> BC <- Base class
> Class_1 <- inherit/subclass/overload from BC
> Class_2 <- inherit/subclass/overload from BC
> Class 3 <- multiply-inherit from Class_1 and Class_2
> Class_3 has all the "methods" (i.e., operations on an object of a specific
> type) from BC, Class_1, and Class_2. The type of Class_3 is compatible
> (individually) with BC, Class_1, and Class_2. For example, any "method"
> invoked on objects of type Class_1 can also be invoked on objects of type
> Class_3 (because Class_3 was derived from Class_1).
> The problem arises when a "base class" is a "virtual base class" (I'm
> speaking in object-oriented terminology of a particular language, but I'm
> trying to keep the discussion very generic). A "virtual base class" has no
> real methods, but only realizes its methods once it is derived (inherited).
> A polygon is a good illustration of a "virtual base class". In this
> illustration, a polygon might have methods "calculate_area" and
> "render_image" because every polygon has these features. However, the
> "calculate_area" method can only be invoked once it is "derived" (via
> inheritance). If BC is a polygon, Class_1 is a triangle, and Class_2 is a
> square, and Class_3 is multiply inherited from Class_1 and Class_2, then
> what is the meaning of "calculate_area"? All four classes have different
> meanings of "calculate_area": BC (yet to be specified), Class_1 (triangle),
> Class_2 (square), Class_3 (conflicting definitions).
There are several perspectives onto that:
1. You adopt common sense and take a square and a triangle to be different
Then it's o.k., that it clashes, since in this sense a thing cannot be a
triangle and square at the same time.
2. You are mathematician:
a. a square is a triangle, because it has three ``angles''.
Then the semantics of a square is compatible /*a specialisation*/ with
the semantics of a triangle. There is no real clash, since Class_2
/*the square*/ is indeed a subclass of Class_1 /*the triangle*/.
b. a square is two triangles [with two common corners].
Now, by making Class_3 the merge of the two, you adopt mathematician's
cases ``a'' and ``b'' at the same time. This will certainly only work
smoothly, if you assure, that the two semantics are not
contradictory. This is in the responsibility of the designer of
Better programming environments supporting multiple inheritance provide a
means to clean up at least the name clash.
> The notion of multiple inheritance (1) only works well on a small scale, and
> (2) only with base concepts (or classes) from taxonomies that are orthogonal
Independence guarantees that multiple inheritance works the simple way.
But it is not that multiple inheritance _only_ works on orthogonal taxonomies.
The technical implementation then has to provide proper means to clean
On the other hand, a good implementation of multiple inheritance supports
factoring out redundancy and so works towards taxonomies to become orthogonal.