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
things:
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
Class_3.
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
> (independent).
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
possible clashes.
On the other hand, a good implementation of multiple inheritance supports
factoring out redundancy and so works towards taxonomies to become orthogonal.
Bye,
Markus