What is the difference between self-types and trait inheritance in Scala?

Question

When Googled, many responses for this topic come up. However, I don't feel like any of them do a good job of illustrating the difference between these two features. So I'd like to try one more time, specifically...

What is something that can be done with self-types and not with inheritance, and vice-versa?

To me, there should be some quantifiable, physical difference between the two, otherwise they are just nominally different.

If Trait A extends B or self-types B, don't they both illustrate that being of B is a requirement? Where is the difference?

Answer 1

If trait A extends B, then mixing in A gives you precisely B plus whatever A adds or extends. In contrast, if trait A has a self reference which is explicitly typed as B, then the ultimate parent class must also mix in B or a descendant type of B (and mix it in first, which is important).

That's the most important difference. In the first case, the precise type of B is crystallised at the point A extends it. In the second, the designer of the parent class gets to decide which version of B is used, at the point where the parent class is composed.

Another difference is where A and B provides methods of the same name. Where A extends B, A's method overrides B's. Where A is mixed in after B, A's method simply wins.

The typed self reference gives you much more freedom; the coupling between A and B is loose.

UPDATE:

Since you're not clear about the benefit of these differences...

If you use direct inheritance, then you create trait A which is B+A. You have set the relationship in stone.

If you use a typed self reference, then anybody who wants to use your trait A in class C could

• Mix B and then A into C.
• Mix a subtype of B and then A into C.
• Mix A into C, where C is a subclass of B.

And this is not the limit of their options, given the way Scala allows you to instantiate a trait directly with a code block as its constructor.

As for the difference between A's method winning, because A is mixed in last, compared to A extending B, consider this...

Where you mix in a sequence of traits, whenever method foo() is invoked, the compiler goes to the last trait mixed in to look for foo(), then (if not found), it traverses the sequence to the left until it finds a trait which implements foo() and uses that. A also has the option to call super.foo(), which also traverses the sequence to the left till it finds an implementation, and so on.

So if A has a typed self reference to B and the writer of A knows that B implements foo(), A can call super.foo() knowing that if nothing else provides foo(), B will. However, the creator of class C has the option to drop any other trait in which implements foo(), and A will get that instead.

Again, this is much more powerful and less limiting than A extending B and directly calling B's version of foo().

Answer 2

I have some code that illustrates some of the differences wrt visibility and "default" implementations when extending vs setting a self-type. It does not illustrate any of the parts discussed already about how actual name collisions are resolved, but instead focuses on what is possible and not possible to do.

trait A1 {
  self: B =>

  def doit {
    println(bar)
  }
}

trait A2 extends B {
  def doit {
    println(bar)
  }
}

trait B {
  def bar = "default bar"
}

trait BX extends B {
  override def bar = "bar bx"
}

trait BY extends B {
  override def bar = "bar by"
}

object Test extends App {
  // object Thing1 extends A1  // FAIL: does not conform to A1 self-type
  object Thing1 extends A1 with B
  object Thing2 extends A2

  object Thing1X extends A1 with BX
  object Thing1Y extends A1 with BY
  object Thing2X extends A2 with BX
  object Thing2Y extends A2 with BY

  Thing1.doit  // default bar
  Thing2.doit  // default bar
  Thing1X.doit // bar bx
  Thing1Y.doit // bar by
  Thing2X.doit // bar bx
  Thing2Y.doit // bar by

  // up-cast
  val a1: A1 = Thing1Y
  val a2: A2 = Thing2Y

  // println(a1.bar)    // FAIL: not visible
  println(a2.bar)       // bar bx
  // println(a2.bary)   // FAIL: not visible
  println(Thing2Y.bary) // 42
}

One important difference IMO is that A1 does not expose that it is needs B to anything that merely sees it as A1 (like illustrated in the up-cast parts). The only code that will actually see that a particular specialisation of B is used, is code that explicitly knows about the composed type (like Think*{X,Y}).

Another point is that A2 (with extension) will actually use B if nothing else is specified while A1 (self-type) does not say that it will use B unless overridden, a concrete B must explicitly be given when objects are instantiated.