Re: Multiple Inheritance [was Re: The joy of FORTRAN]

On 10/1/24 22:47, Lawrence D'Oliveiro wrote:

On Tue, 1 Oct 2024 15:57:36 +0100, Pancho wrote:
 

On 9/30/24 22:19, Lawrence D'Oliveiro wrote:
>

But it makes the difference between multiple inheritance that bewilders
and confuses people, and multiple inheritance which makes sense. It’s
what lets Python have multiple inheritance that makes sense.

>
There is a difference between a consistent implementation of multiple
inheritance and something that people actually understand when coding,
or maintaining code.
>
In essence just because you can do something clever, doesn't mean you
should.

 A clever idea worth using is one that saves programmer work and
implementation overhead.
 

There is a balance between being concise and being clear. You mentioned parenthesis. I like redundant parenthesis, if they save me a second thinking about evaluation order. If there is a chance for confusion, it is best to be explicit.

For example, consider enumerated types. Java and C++ have to define these
as part of the core language. But Python does not: enums are provided by a
standard library module, written in pure Python -- there is nothing it
does that you cannot do in your own Python code.
 

Deep down, I don't really care about enums. They are nice to have, intellisense mainly, but I don't want to spend time thinking about them.

This enum implementation is built on two important ideas from the core
language -- multiple inheritance, and metaclasses -- in order to do its
thing. As a result, it can do everything that Java enums can do, for
example, and more besides. And the result is very easy to use: you don’t
need to understand all the intricacies of the mechanisms concerned to
define simple enums.
 (Want examples? Just ask.)
 

Think about why languages like Java and PHP avoided multiple
inheritance, and substituted those lame “interfaces” instead: it was to
avoid this bewilderment and confusion that is known to plague C++,
because the right solution wasn’t known at the time.
>

I quite like interfaces, polymorphism through interfaces.

 “Interfaces” are just “abstract base classes lite”. They are a way to
provide a very limited form of multiple inheritance, in the hope that this
would somehow avoid the bewilderment that comes from multiple inheritance
as done in C++.
 

"Pure virtual classes" rather than abstract. We did this in C++ before Java and its interfaces existed. In fact it was the one use of multiple inheritance we were allowed to use. For me this was just received wisdom from on high, I didn't think about it at the time, but it mapped to Java use of interfaces.

Do they succeed? You yourself said “Single inheritance bewilders and
confuses people”, so I don’t think they did.
 

The common problem with single inheritance is depth. Trying to understand where a method is implemented. Trying to understand what changing a method will do to sub classes.
In practice, interfaces were 1 level deep. I found this worked well. Was easy to understand. Because they were one level deep none of the problems of multiple inheritance occurred.
Maybe this is different if you are designing libraries, but I wasn't. I was top of the code food chain,using libraries, not building them.

I had a look, it would take me a while to work through the algorithm,
establish how the ideas sit in the more common language of DAGs and
graph theory.

 The gist of it is, the linearization algorithm from CLOS was refined a bit
for Dylan. And C3 is in turn a refinement of the linearization used in
Dylan.
 

If there is a significant difference that requires new
terms such as monotonic.

 “Monotonic” was not a new term in OO at the time of publication of that
paper. In fact, the concept exposed some of the deficiencies that C3
sought to address.

Monotonic might not be a new term, but it looks similar to partial order. I don't understand what it means in this context. I guess most programmers wouldn't. If we have single level interface inheritance we don't need to.
There is a trade off between a software language being simple, and being able to neatly solve all problems. As languages mature they tend to sacrifice simplicity, in order to address problems in rare use cases. I'm very dubious that this is a good idea. i.e. I suspect for many normal tasks, software developers are more productive with simpler languages.