Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

(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?

share|improve this question
    
Sharing your research helps everyone. 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 How to Ask –  gnat Apr 26 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 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 at 19:43
5  
Reading that statement doesn't tell you HOW just that it does. –  Mike Brown Apr 26 at 20:05

2 Answers 2

up vote 6 down vote accepted

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 inherit B and C, and both B and C's constructors call A's constructor, than 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.

share|improve this answer
    
It's possible to use 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 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 at 10:37

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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