http://copute.com/dev/docs/Copute/ref/class.html#Inheritance (review the references cited there for Scala too)

There is no multiple inheritance. All implementation in traits are folded into the single-inheritance on per member basis and it is called “linearization”. And any duplicate members MUST be resolved by the subclass.

Err…what?

Yes, the compiler *does* do some clever tricks to fold MI into the inheritance chain. So?

If you really wanted to, you could do the same thing for a language with ”no” proper implementation inheritance.

interface Foo {
Foo clone();
Foo next();
Foo plusBy(int n);
}
class Foo$class {
static Foo plusBy(Foo this_t, int n) {
Foo res = null;
for (i = 0; i < n; i++) res = res.next();
return res
}
}
class Bar implements Foo {
private int i;
Bar(int i) {this.i = i}
Foo clone() { return this; }
Foo next() {return new Bar(i+1) }
Foo plusBy(int n) {return Foo$class.plusBy(this, n)}
}

However, that’s really not the point. If there was a compiler that turned Scala into C++, then traits could become Multiple Inheritance proper. Yes, Scala doesn’t have full MI, but it does have some. Heck, even Java has some, with multiple interface inheritance.

Actually, come to think of it, what you said isn’t strictly true. The implementation inheritance is folded away into the single-inheritance chain–well, actually, it’s usually folded into the class itself, but that’s not the point–but the interface of the trait is inherited as normal, and more than one interface may be inherited. Scala isn’t a strictly MI language, but don’t call it a Single-Inheritance one.

Don’t conflate some programmer’s insufficient separation-of-concerns in the design of a trait with the Diamond Problem.The Diamond Problem is a specific problem of how to resolve multiple inheritance name spaces (scope).

Also please realize that Scala is a single-inheritance language, with the apparency of multiple inheritance of traits. In reality, traits get folded into that single-inheritance chain in a specific order and are NOT multiply inherited.

You missed the point of mixins. They completely solve the diamond problem because only duplicate methods which are from the EXACT SAME trait are resolved automatically. Any duplicates from different traits have to be resolved by the superclass in the single-inheritance chain (i.e. analogous to “Class::” in C++).

You can’t do “Class::” specific method call from a trait (you must use the less specific “super.” instead), this because mixin order can insert an mixin in middle of the inheritance hierarchy of another mixin. For example, given mixin A (B) and mixin C (B), then mixin D (C,A) would effectively cause mixin C (A,B), because the B in mixin C (B) is already in the inheritance tree of mixin A (B), and thus not repeated. A more detailed explanation can be found at top, left of page 7 in the Super subsection of the 2.2 Modular Mixin Composition section of Scalable Component Abstractions, Odersky & Zenger, Proceedings of OOPSLA 2005, San Diego, October 2005.

http://www.scala-lang.org/sites/default/files/odersky/ScalableComponent.pdf

So I want you to realized that “Class::” specific method invocation can never be as flexible as mixins.

I studied this deeply for the design of my Copute language.

I think that traits are much better than interfaces. Why? Because you don’t have to use what they provide, but they give you some useful things. For example, the Monad trait, provided you implement flatMap[B](fn : A => M[B]) : M[B], defines the following for you:

def flatMap[B, That](fn : A => M[B])(implicit bf : CanBuildFrom[M, B, That]) : That
// flatMaps, then converts to type That, eg, from Array[T] to List[T], or String, Int…provided you can tell it how to do so with a CanBuildFrom subclass.
def map[B](fn : A => B) : M[B]
def map[B, That](fn : A => B)(implicit bf : CanBuildFrom[M, B, That]) : That
// maps, then builds into type That.
def foreach(fn : A => Unit) : Unit

Don’t understand any of that? Good. You don’t have to, thanks to traits.

Traits were introduced by Prof.Ducasse at the University of Berne: http://citeseer.ist.psu.edu/566972.html and first implemented in Squeak Smalltalk. SInce Lausanne is not that far away from Lausanne, where the Scala resides, these people might have exchanged ideas …

Anyways, great article series. Really got me started on learning Scala.

I’m loving your series of articles thus far. This is the first one I’ve commented on. I wanted to point out that overloading “extends” (in my humble opinion, of course) is no worse than overloading “&lt”. In fact, I’d argue that Scala heavily overloads parens, angle brackets, and many others, much more so than Java does. Flexible? Yes, definitely — but I wouldn’t say that somehow overloading “extends” (which starts with far fewer meanings than “&lt” and “&gt” do) doesn’t seem *that* bad. I think I’d prefer something else to signify structural type restrictions of a generic type.