[incepted]

> 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.

[TylerE]

But isn't that sort of the point? Traits aren't multiple inheritance.

[riffraff]

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).

[0] https://en.wikipedia.org/wiki/Object-Oriented_Software_Const... [1] http://www.ptidej.net/courses/ift6251/fall06/presentations/0...

[seanmcdirmid]

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.

[qznc]

Don't forget C++ traits, which are more like a design pattern.

[pjmlp]

CS papers about it might disagree.