MI Hownotto by Betrand Meyer

MI Hownotto by Betrand Meyer

[Georg Bauhaus]

This week's EiffelWorld column by Bertrand Meyer has a note
about construction procedures and multiple inheritance.
I thought it might be interesting given a recent discussion
in c.l.ada.

<quote ref="EiffelWorld Electronic Newsletter -- Vol. 33, No 2, Section 4">
In particular, multiple inheritance just doesn't go well with the
C++ idea, also retained in Java and C#, that a constructor (creation
procedure) must start its execution by calling the constructor of
its parent. As soon as you require this you are ruling out multiple
inheritance, since with two parents or more there's no good reason for
executing a particular parent's constructor before the others'; and
the situation becomes even more hazy when these parents have a common
ancestor -- repeated inheritance, the so called "diamond" structure.
Hence complicated rules that probably about twelve people in the world
understand, and fewer remember.</quote>

Re: MI Hownotto by Betrand Meyer

[Dmitry A. Kazakov]

On Sat, 28 Oct 2006 15:54:48 +0200, Georg Bauhaus wrote:

> This week's EiffelWorld column by Bertrand Meyer has a note
> about construction procedures and multiple inheritance.
> I thought it might be interesting given a recent discussion
> in c.l.ada.
> 
> <quote ref="EiffelWorld Electronic Newsletter -- Vol. 33, No 2, Section 4">
> In particular, multiple inheritance just doesn't go well with the
> C++ idea, also retained in Java and C#, that a constructor (creation
> procedure) must start its execution by calling the constructor of
> its parent. As soon as you require this you are ruling out multiple
> inheritance, since with two parents or more there's no good reason for
> executing a particular parent's constructor before the others'; and
> the situation becomes even more hazy when these parents have a common
> ancestor -- repeated inheritance, the so called "diamond" structure.
> Hence complicated rules that probably about twelve people in the world
> understand, and fewer remember.</quote>

Hmm, maybe the quote was taken out of context, but I don't really think
that constructors are responsible "diamond." The issue, as I see it, is
deeper. It is independent on constructors and, notably, even on whether
implementation (like record members) or just interfaces are inherited.

MI definitely adds complexity. In C++ it is quite difficult to deal with,
and construction issues become catastrophic. But what were an alternative
to MI?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: MI Hownotto by Betrand Meyer

[Alexander E. Kopilovich]

Dmitry A. Kazakov wrote:

> But what were an alternative to MI?

Perhaps a proper alternative to MI may be a set of different kinds of MI (each
equipped with its own name) instead of a single notion overloaded with complex
rules.

Look at algebra for a good example: there we have different compositions of
two algebraic objects - direct sum, direct product, tensor product etc.
Mathematicians do not try to pack all those things into one overcomplicated
notion for everyday use. (But for those, and only for those, who like or need
generalizations, there is category theory and the notion of universal object
in category, which covers all those cases - just describe a suitable category
and you'll get a particular construction from the general categorical notion.)

Re: MI Hownotto by Betrand Meyer

[Dmitry A. Kazakov]

On Sun, 29 Oct 2006 06:39:07 +0300 (MSK), Alexander E. Kopilovich wrote:

> Dmitry A. Kazakov wrote:
> 
>> But what were an alternative to MI?
> 
> Perhaps a proper alternative to MI may be a set of different kinds of MI (each
> equipped with its own name) instead of a single notion overloaded with complex
> rules.
>
> Look at algebra for a good example: there we have different compositions of
> two algebraic objects - direct sum, direct product, tensor product etc.
> Mathematicians do not try to pack all those things into one overcomplicated
> notion for everyday use.

To me these refer to just one case, which is already handled quite well.
That's when the structure of inheritance is a DAG. [ OK, there are minor
naming problems, but mathematicians are accustomed to extremely hairy
notations. (:-)) ]

Mathematical structures are simple (I don't mean the sematic of) comparing
with ones found in programming. The reason is that the declarative
framework of a programming language surpasses human's abilities by margin.
This allows us to construct things, which nobody could understand in all
necessary details if they were just written on paper.

Surely a study of algebraic properties of type structures is necessary.
However I don't think it would leave us with a smaller number of cases.
Group theory is an example, that this need not to happen. I think we will
end up with far more complex things than diamond diagram.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de