How do Traits in Scala avoid the "diamond error"?

Question

(Note: I used 'error' instead of 'problem' in the title for obvious reasons.. ;) ).

I did some basic reading on Traits in Scala. They're similar to Interfaces in Java or C#, but they do allow for default implementation of a method.

I was wondering: can't this cause a case of the "diamond problem", which is why many languages avoid multiple inheritance in the first place?

If so, how does Scala handle this?

[Sharing your research helps everyone](http://meta.programmers.stackexchange.com/questions/6559/why-is-research-important). Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see [ask] — gnat, Apr 26 '14 at 19:16
@gnat: this is a conceptual question, not a concrete problem question. If he was asking "I have this class in Scala and it's giving me problems that I think might be related to the Diamond Problem, how do I fix it?" then your comment would be appropriate, but then the question would belong on SO. :P — Mason Wheeler, Apr 26 '14 at 19:34
@MasonWheeler I did some basic reading on Scala too. And first search for "diamond" in what I've read gave me the answer: "A trait has all the features of the Java interface construct. But traits can have implemented methods on them. If you are familiar with Ruby, traits are similar to Ruby’s mixins. You can mix many traits into a single class. Traits cannot take constructor parameters, but other than that they behave like classes. This gives you the ability to have something that approaches multiple inheritance without the diamond problem". Lack of effort in this question feels rather blatant — gnat, Apr 26 '14 at 19:43
Reading that statement doesn't tell you HOW just that it does. — Michael Brown, Apr 26 '14 at 20:05

score 29 · Accepted Answer · edited Mar 04 '23 at 13:32

29

The diamond problem is the inability to decide which implementation of the method to choose. Scala solves this by defining which implementation to choose as part of the language specifications(read the part about Scala in this Wikipedia article).

Ofcourse, same order definition could also be used in class multiple inheritance, so why bother with traits?

The reason IMO is constructors. Constructors have several limitations that regular methods don't have - they can only be called once per object, they have to be called for each new object, and a child class' constructor must call it's parent's constructor as it's first instruction(most languages will do it implicitly for you if you don't need to pass parameters).

If B and C inherit A, and D inherits B and C, and both B and C's constructors call A's constructor, then D's constructor will call A's constructor twice. Defining which implementations to choose like Scala did with methods won't work here because both B's and C's constructors must be called.

Traits avoid this problem since they don't have constructors.

edited Mar 04 '23 at 13:32

doubleYou

2,737
1
11
25

answered Apr 26 '14 at 20:04

Idan Arye

12,032
31
40

1

It's possible to use [C3 linearization](https://en.wikipedia.org/wiki/C3_linearization) to call the constructors once and only once - that's how Python does multiple inheritance. Off the top of my head the linearization for the D < B|C < A diamond is D -> B -> C -> A. Moreover, a google search has showed me that Scala traits can have mutable variables, so surely there's a constructor somewhere in there? But if it's using composition under the hood (I don't know, never used Scala) it's not hard to see that B and C could share on instance of A... – Doval May 14 '14 at 10:33
...Traits just seem like a very concise way to express all the boilerplate that goes into combining interface inheritance and composition + delegation, which is the correct way to reuse behavior. – Doval May 14 '14 at 10:37
@Doval My experience of constructors in multiply inherited Python is that they're a royal pain. Each constructor can't know which order it'll be called in, so doesn't know what the signature of its parent constructor is. The usual solution is for every constructor to take a bunch of keyword arguments, and pass the unused ones onto its super constructor, but if you need to work with an existing class that doesn't follow that convention, you can't safely inherit from it. – James_pic Oct 08 '15 at 09:17
Another question is that why C++ did not choose sane policy for diamond problem? – user Apr 19 '16 at 23:27

score 26 · Answer 2 · answered May 14 '14 at 09:25

Scala avoids the diamond problem by something called "trait linearization". Basically, it looks up the method implementation in the traits you extend from right to left. Simple example:

trait Base {
   def op: String
}

trait Foo extends Base {
   override def op = "foo"
}

trait Bar extends Base {
   override def op = "bar"
}

class A extends Foo with Bar
class B extends Bar with Foo

(new A).op
// res0: String = bar

(new B).op
// res1: String = foo

Having said that, the list of traits it looks up might contain more than the ones you explicitly gave, since they might extend other traits. A detailed explanation is given here: Traits as stackable modifications and a more complete example of the linearization here: Why not multiple inheritance?

I believe in other programming languages this behavior is sometimes referred to as "Method resolution order" or "MRO".

How do Traits in Scala avoid the "diamond error"?

2 Answers2