C++ has plain multiple inheritance, many language designs forbid it as dangerous. But some languages like Ruby and PHP use strange syntax to do the same thing and call it mixins or traits. I heard many times that mixins/traits are harder to abuse than plain multiple inheritance.

What specifically makes them less dangerous? Is there something that isn't possible with mixins/traits but possible with C++-style multiple inheritance? Is it possible to run into the diamond problem with them?

This seems as if we were using multiple inheritance but just making excuses that those are mixins/traits so we can use them.

  • 7
    Looking forward to someone posting a well-written, thoughtful and thorough answer to this one. – Robert Harvey Jul 22 '14 at 20:38
  • 7
    Ruby and PHP didn't introduce mixins and traits. Mixins were introduced in Flavors (1980), Traits were introduced in Squeak Smalltalk (2001). Flavors was the very first object-oriented language with multiple inheritance, and it used mixins. C++ only got multiple inheritance in version 2.0, which was released in 1989, 9 years after Flavors. So, the question should be: Flavors has plain mixins, but some languages like C++ introduce strange syntax to do the same thing and call it multiple inheritance. – Jörg W Mittag Jul 23 '14 at 0:15
up vote 30 down vote accepted

There are a number of problems with multiple inheritance when it is used with full fledged classes, but they all revolve around ambiguity.

The ambiguity shows up in a few different ways:

  1. If you have two base classes with the same field x, and the derived type asks for x, what does it get?
    • If the two x variables have incongruent types, you could infer it.
    • If they're the same type, you could try to merge them into the same variable.
    • You could always expose them as weird fully qualified names.
  2. If you have two base classes with the same function f with identical signatures, and someone calls f, which gets called?
    • What if the two base classes share another common virtual ancestor (the diamond problem).
    • What if the function has different, but compatible signatures?
  3. When you construct a class with two base classes, which of the base classes' constructor is called first? When you destroy the object, which is killed?
  4. When you lay out the object in memory, how do you do it consistently?
  5. How do you handle all of these cases with 3 base classes? 10?

And that ignores things like dynamic dispatch, type inference, pattern matching and other things I know less about which become more challenging when the language supports multiple inheritance of full classes.

Traits or Mix-ins (or interfaces, or...) are all constructs which specifically limit a type's capabilities so that there is no ambiguity. They rarely own anything themselves. This allows the composition of types to go smoother because there's not two variables or two functions... there is a variable and a reference; a function and a signature. The compiler knows what to do.

The other common approach taken is to force the user to "build" (or mix in) their type one at a time. Instead of the base classes being equal partners in the new type, you add one type to another - overriding anything that was there (usually with optional syntax to re-name and/or re-expose the overridden bits).

Is there something that isn't possible with mixins/traits but possible with C++-style multiple inheritance?

Depending on the language - it generally becomes troublesome or impossible to merge implementations of functions and storage for variables from multiple base classes and expose them in the derived type.

Is it possible to run into diamond problem with them?

Occasionally less severe variations will pop up based on your language, but usually no. The entire point of traits are to break that sort of ambiguity.

  • Can you give me exemple of the language/technology allowing such "building" types for an instance? – Gherman Jul 22 '14 at 21:31
  • @german - I am certainly no Scala expert, but my understanding is that is what the with keyword does there. – Telastyn Jul 22 '14 at 22:55
  • "constructs which specifically limit a type's capabilities so that there is no ambiguity": what sort of limits? Interfaces don't have variables, so that's one limit, but Scala traits and Ruby modules do. Are they limited in other ways? – David Moles Jul 17 '15 at 17:12
  • @DavidMoles - that's the common way, I've also seen limitations on virtual dispatch rules (think C#'s explicitly implemented interfaces). – Telastyn Jul 17 '15 at 18:56

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.