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

Question

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

On the other hand, the following:

trait B
trait A extends B

says that "any (concrete or abstract) class mixing in A will also be mixing in B".

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.

What am I missing?

Solution 1

It is predominately used for Dependency Injection, such as in the Cake Pattern. There exists a great article covering many different forms of dependency injection in Scala, including the Cake Pattern. If you Google "Cake Pattern and Scala", you'll get many links, including presentations and videos. For now, here is a link to another question.

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 use self-types, B requires an A. There are two specific requirements that are created with self-types:

1. If B is extended, then you're required to mix-in an A.
2. When a concrete class finally extends/mixes-in these traits, some class/trait must implement A.

Consider the following examples:

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

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

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

If Tweeter was a subclass of User, there would be no error. In the code above, we required a User whenever Tweeter is used, however a User wasn't provided to Wrong, so we got an error. Now, with the code above still in scope, consider:

scala> trait DummyUser extends User {
     |   override def name: String = "foo"
     | }
defined trait DummyUser

scala> trait Right extends Tweeter with User {
     |   val canDo = name
     | }
defined trait Right 

scala> trait RightAgain extends Tweeter with DummyUser {
     |   val canDo = name
     | }
defined trait RightAgain

With Right, the requirement to mix-in a User is satisfied. However, the second requirement mentioned above is not satisfied: the burden of implementing User still remains for classes/traits which extend Right.

With RightAgain both requirements are satisfied. A User and an implementation of User are provided.

For more practical use cases, please see the links at the start of this answer! But, hopefully now you get it.

Solution 2

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.

Solution 3

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.

Solution 4

Another thing that has not been mentioned: because self-types aren't part of the hierarchy of the required class they can be excluded from pattern matching, especially when you are exhaustively matching against a sealed hierarchy. This is convenient when you want to model orthogonal behaviors such as:

sealed trait Person
trait Student extends Person
trait Teacher extends Person
trait Adult { this : Person => } // orthogonal to its condition

val p : Person = new Student {}
p match {
  case s : Student => println("a student")
  case t : Teacher => println("a teacher")
} // that's it we're exhaustive

Solution 5

Section 2.3 "Selftype Annotations" of Martin Odersky's original Scala paper Scalable Component Abstractions actually explains the purpose of selftype beyond mixin composition very well: provide an alternative way of associating a class with an abstract type.

The example given in the paper was like the following, and it doesn't seem to have an elegant subclass correspondent:

abstract class Graph {
  type Node <: BaseNode;
  class BaseNode {
    self: Node =>
    def connectWith(n: Node): Edge =
      new Edge(self, n);
  }
  class Edge(from: Node, to: Node) {
    def source() = from;
    def target() = to;
  }
}

class LabeledGraph extends Graph {
  class Node(label: String) extends BaseNode {
    def getLabel: String = label;
    def self: Node = this;
  }
}

View more solutions

Comments

[Dave]

I hadn't considered this scenario. Its the first example of something that I've seen that isn't the same as a self-type as it is with a subclass. However, it seems kind of edge-casey and, more important, it seems like a bad idea (I usually go far out of my way NOT to define cyclic dependencies!). Do you find this to be the most important distinction?

[Dave]

Thanks. The Cake pattern is 90% of what I mean why I talk about the hype around self-types... it is where I first saw the topic. Jonas Boner's example is great because it underscores the point of my question. If you changed the self-types in his heater example to be subtraits then what would be the difference (other than the error you get when defining the ComponentRegistry if you don't mix in the right stuff?

[Daniel C. Sobral]

@Dave: You mean like trait WarmerComponentImpl extends SensorDeviceComponent with OnOffDeviceComponent? That would cause WarmerComponentImpl to have those interfaces. They would be available to anything that extended WarmerComponentImpl, which is clearly wrong, as it is not a SensorDeviceComponent, nor a OnOffDeviceComponent. As a self type, these dependencies are available exclusively to WarmerComponentImpl. A List could be used as an Array, and vice versa. But they just aren't the same thing.

[Dave]

Thanks Daniel. This is probably the major distinction I was looking for. The practical problem is that using subclassing will leak functionality into your interface that you don't intend. Its a result of the violation of the more theoretical "is-part-of-a" rule for traits. Self-types express a "uses-a" relationship between parts.

[Mushtaq Ahmed]

I think so. I do not see any other reason why I would prefer self-types to extends clause. Self-types are verbose, they do not get inherited (so you have to add self-types to all subtypes as a ritual) and you can only see member but can't override them. I am well aware of Cake pattern and many posts mentioning self-types for DI. But somehow I am not convinced. I had created a sample app here long back (bitbucket.org/mushtaq/scala-di). Look specifically at /src/configs folder. I achieved DI to replace complex Spring configurations without self-types.

[Daniel C. Sobral]

@Dave: Yes. It's perhaps interesting to note that traits and self-types are, perhaps, most important when using object as modules. Or, at least, that's how I see it. Not necessarily an object, either, which is a singleton.

[Dave]

Mushtaq, we're in agreement. I think Daniel's statement about not exposing unintentional functionality is an important one but, as you put it, there is a mirror view of this 'feature'... that you cannot override the functionality or use it in future subclasses. This pretty clearly tells me when design will call for one over the other. I'll be avoiding self-types until I find a genuine need -- ie if I start using objects as modules as Daniel points out. I'm autowiring dependencies with implicit parameters and a straightforward bootstrapper object. I like the simplicity.

[Rodney Gitzel]

The second trait should read "this: User =>" instead of "user: User =>"

[Daniel C. Sobral]

@Rodney No, it shouldn't. In fact, using this with self types is something I look down upon, since it shadows for no good reason the original this.

[Rodney Gitzel]

Hmmm. Ah, my bad, when I pasted "user:" I got a pasting error, not a compiling error. But that begs a question of why even bother to name the self-type? To resolve ambiguities, I guess: "user.name" can be used instead of just "name". So definitely using "this" is a bad idea... how would you access the real this?

[Adrian]

Actually you can use inheritance with structural types too: abstract class A extends {def close:Unit}

[Andrew E]

The url of the article that Mushtaq posted has changed slightly: jonasboner.com/2008/10/06/…

[rintcius]

@DanielC.Sobral may be thanks to your comment but at the moment it has more upvotes than your anser. Upvoting both :)

[Morgan Creighton]

Employee does not need to be a class to descend from Person. Traits can extend classes. If the Employee trait extended Person instead of using a self type, the example would still work. I find your example interesting, but it doesn't seem to illustrate a use case for self types.

[Petr]

@MorganCreighton Fair enough, I didn't know that traits can extend classes. I'll think about it if I can find a better example.

[Morgan Creighton]

Yes, it's a surprising language feature. If trait Employee extended class Person, then whatever class ultimately "withed in" Employee would also have to extend Person. But that restriction is still present if Employee used a self type instead of extending Person. Cheers, Petr!

[opensas]

Excellent answer, BTW, how can you express more than one dependency? I tried with (dep1: Dep1, dep2: Dep2) => { xxx }, and it compiles, but it doesn't check for the dependencies...

[Daniel C. Sobral]

@opensas Try self: Dep1 with Dep2 =>.

[AmigoNico]

@Blaisorblade: I wonder whether you might have misread kikibobo's answer -- a trait's self type does indeed allow you to constrain the types that may mix it in, and that is part of its usefulness. For example, if we define trait A { self:B => ... } then a declaration X with A is only valid if X extends B. Yes, you can say X with A with Q, where Q does not extend B, but I believe kikibobo's point was that X is so constrained. Or did I miss something?

[Blaisorblade]

Thanks, you're right. My vote was locked, but luckily I could edit the answer and then change my vote.

[Eran Medan]

I think structural typing is using reflection, so use only when there is no other choice...

[Kevin Meredith]

so, @DanielC.Sobral, adding ... with User to trait Wrong extends Tweeter will fix this issue since using the self-trait means that it must have a User?

[Robin Green]

I don't see why "this is only meaningful if Expense extends Person or vice versa."

[Robin Green]

No, B can be (and indeed is) an "abstract trait" in both cases. So there is no difference from that perspective.

[Alexey]

@Adrian, I believe your comment is incorrect. ` abstract class A extends {def close:Unit}` is just an abstract class with Object superclass. it's just a Scala's permissive syntax to nonsensical expressions. You can ` class X extends { def f = 1 }; new X().f` for example

[Adrian]

@Alexey I don't see why is your example (or mine) nonsensical.

[Alexey]

@Adrian, abstract class A extends {def close:Unit} is equivalent to abstract class A {def close:Unit} . So it does not involve structural types.

[Ivaylo Toskov]

Thank you for this answer! Could someone point out the difference between writing user: User =>, self: User => and this: User =>?

[BrunoMedeiros]

@IvayloToskov they are nearly identical. They all require the type of this to be User, but they optionally also introduce the user or self identifier as an alias for this. So with trait Tweeter { user: User => you can write user.name in addition to this.name inside Tweeter.

[BrunoMedeiros]

@DanielC.Sobral I don't think your answer is correct: You said "When you do dependency injection, you want B to require A, not to be an A. " - well, that might be true for DI in general, but not for the self-type syntax being discussed here. Namely, in your example: trait Tweeter { user: User => // ... , the self-type declaration does require concrete types implementing Tweeter to be a User too (similar to having trait Tweeter extends User instead). That's why trait Wrong extends Tweeter is an error, but trait Wrong extends Tweeter with User { works.

[Luke Maurer]

For those wondering why subclassing won't solve this, Section 2.3 also says this: “Each of the operands of a mixin composition C_0 with ... with C_n, must refer to a class. The mixin composition mechanism does not allow any C_i to refer to an abstract type. This restriction makes it possible to statically check for ambiguities and override conflicts at the point where a class is composed.”

[ari gold]

The article changed URL again: jonasboner.com/real-world-scala-dependency-injection-di

[MaxNevermind]

keep your answers short or add tl;dr @jazmit's answer bellow can give you a clue

[Rich Oliver]

Why not just create one trait AB? As traits A and B must always be combined in any final class, why separate them in the first place?

[Kevin Dreßler]

@RichOliver I guess the answer is that you simlpy don't control each and every trait in the universe.

[soMuchToLearnAndShare]

Why is it called self-type? Conceptually I cannot make a sense out of the naming, hence difficult to remember/use.