What is the difference between scala self-types and trait subclasses?

Question

Self-types seem to be important so I want to know why they are useful. From what I can gather, a self-type for a trait A:

trait B
trait A { this: B => }

says that "A cannot be mixed into a concrete class that does not also extend B".

(sidenote: I'm also seeing this fail in the REPL when mixed into an abstract class that does not extend B, which the book "Programming in Scala" says should work, but I'm using a Scala 2.8 daily build.)

But if I say:

trait B
trait A extends B

then this means that "any (concrete or abstract) class mixing in A will also be mixing in B". But don't these two statements mean the same thing? The self-type seems to serve only to create the possibility of a simple compile-time error.

I have considered that the difference may be the order of function overloading when using a self-type instead of an extends clause... but this seems like a minor distinction, not worthy of the hoopla over self-types. What am I missing?

Answer 1

in the first case, a sub-trait or sub-class of B can be mixed in to whatever uses A. So B can be an abstract trait.

Answer 2

A self type lets you specify what types are allowed to mixin a trait. For example, if you have a trait with a self type "Closeable", then that trait knows that the only things that are allowed to mix it in, must implement the Closeable interface.

Answer 3

Self types allow you to define cyclical dependencies. For example you can achieve this:

trait A {self: B=>}
trait B {self: A=>}

Inheritance using extends does not allow that. Try:

trait A extends B
trait B extends A
error:  illegal cyclic reference involving trait A

In the Odersky book, look at section 33.5 (Creating spreadsheet UI chapter) where it mentions:

In the spreadsheet example, class Model inherits from Evaluator and thus gains access to its evaluation method. To go the other way, class Evaluator defines its self type to be Model, like this:

package org.stairwaybook.scells
trait Evaluator { this: Model => ...

Hope this helps.

Answer 4

It is used for Dependency Injection, such as in the Cake Pattern. I once read a great article covering many different forms of dependency injection in Scala, including the Cake Pattern, but I can't find it right now (edit: thanks to Mushtaq, it is now linked). If you look up google for Cake Pattern and Scala, you'll get many links, including presentations and videos. For now, there's a publicly-available chapter of O'Reilly's Programming Scala book with a section on it.

Now, as to what is the difference between a self type and extending a trait, that is simple. If you say B extends A, then B is an A. When you do dependency injection, you want B to require A, not to be an A. For example:

scala> trait User { def name: String }
defined trait User

scala> trait Tweeter {
     |   user: User =>
     |   def tweet(msg: String) = println(name+": "+msg)
     | }
defined trait Tweeter

scala> trait Wrong extends Tweeter {
     |   def noCanDo = name
     | }
<console>:8: error: illegal inheritance;
 self-type Wrong does not conform to Tweeter's selftype Tweeter with User
       trait Wrong extends Tweeter {
                           ^
$iw.$iw.Wrong <: $iw.$iw.Tweeter with $iw.$iw.User?
  $iw.$iw.Wrong <: $iw.$iw.Tweeter?
  true
  $iw.$iw.Wrong <: $iw.$iw.User?
    <notype> <: $iw.$iw.User?
    false
  false
false
<console>:9: error: not found: value name
         def noCanDo = name
                       ^

Which would cause no error if subclassing was used.

Answer 5

One additional difference is that self-types can specify non-class types. For instance

trait Foo{ this => {def close:Unit} }

The self type here is a structural type. The effect is to say that anything that mixes in Foo must implement a no-arg "close" method returning unit. This allows for safe mixins for duck-typing.