Pardon my ignorance but I thought by now everyone agreed that Multiple inheritance was the root of all evil. (That and the others). Also I, like many, have moved towards greener pasture, such as composition over inheritance. Did I miss a train?
Well, lots of languages have mixins or traits, which is pretty similar. Also multiple inheritance got a bad rep through C++'s particular implementation of it, but it doesn't need to get so messy.
Eiffel, for example, a language that nobody uses but that people like me love to discuss in OO related debates, has much simpler and better support for multiple inheritance: If theres any clash of methods (name+signature) from different parents, you must choose which one the child class gets or it won't compile.
Im not sure what Nit does, but it might not be as brain dead as waht C++ does.
Finally, I prefer composition over inheritance too, but on the other side many of my React components have multiple mixins. I couldnt do that if I had used ES6 classes. Given that Nit seems targeted at UIs (android, obcj support), I guess it makes a lot of sense.
Can't you have "mixins" with ES6 classes by decorating them (e.g. applying a function to the class which adds the desired behaviour)? Related ECMAscript proposal which adds some syntax sugar: https://github.com/wycats/javascript-decorators
> Pardon my ignorance but I thought by now everyone agreed that Multiple inheritance was the root of all evil.
Hardly.
How it's implemented makes the difference. I'd say the general consensus is that C++' version of it is probably the worst (although to be fair, as much as I dislike C++, its implementation of MI has never really bothered me much in practice).
Modern languages support multiple inheritance of implementations with traits, which have a few additional restrictions compared to classes. These restrictions address some of the flaws that MI can have.
The bottom line is that you will rarely need MI and when you do, its flaws will probably not be much of a hindrance, so overall, it's a pretty overblown problem.
O think there is a problem with multiple inheritance being somewhat ill-defined.
I recall reading OOSC[0], where Meyer showed that MI in Eiffel is fine, and it basically boiled down to: when there is an ambiguity, force the child class to rename the conflicting methods/redefine them, which is very close to what the original traits paper[1] suggests (bar state in traits, IIRC).
There are multiple meanings of traits flying around in different languages. Some traits are type classes (Rust), some traits are mixins (Scala). The former are not really related to class-based inheritance, while the latter most definitely is (linearized multiple inheritance as defined by Cook & Bracha, not the mixins of CommonLisp). Self and smalltalk style traits are even more different.
Mutliple inheritence can work quite nicely, assuming a reasonable "linearization" algorithm that decides what order `super` should use when walking up the class hierarchy, so that no method needs to worry about calling into multiple parent classes. The last I looked at the research, the gold standard for linearization was the C3 algorithm:
This is supposedly used by Python, by recent versions of Dylan, and by Perl 6. I've worked in projects that used extensive multiple inheritance and superclass linearization, and it's not bad at all. Now, that doesn't mean that inheritance is always an optimal design—composition and traits are both extremely useful—but multiple inheritance can work fairly well.
