В чем разница между типами self и подклассами черт?

Типы типов позволяют вам определять циклические зависимости. Например, вы можете достичь этого:

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

Наследование с использованием extends не позволяет этого. Попробуйте:

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

В книге Odersky посмотрите раздел 33.5 (Создание главы пользовательского интерфейса электронной таблицы), где он упоминает:

В примере электронной таблицы класс Model наследует от Evaluator и таким образом, получает доступ к методу оценки. Чтобы пойти другим путем, класс Оценщик определяет свой тип типа как Модель:

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

Надеюсь, что это поможет.

Еще одно отличие состоит в том, что типы self-types могут указывать типы неклассов. Например,

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

Тип типа здесь является структурным типом. Эффект состоит в том, чтобы сказать, что все, что смешивается в Foo, должно реализовать возвращаемый модуль метода no-arg "close". Это позволяет использовать безопасные микшины для утиного ввода.

Еще одна вещь, о которой не упоминалось: поскольку сами типы не являются частью иерархии требуемого класса, они могут быть исключены из сопоставления шаблонов, особенно когда вы исчерпывающе сопоставляетесь с запечатанной иерархией. Это удобно, если вы хотите моделировать ортогональное поведение, например:

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 it we're exhaustive

Раздел 2.3 "Аннотации самодельного изображения" оригинального макета Scala paper Масштабируемые абстракции компонентов на самом деле очень хорошо объясняет цель самолечения за пределами состава смеси: обеспечить альтернативный способ ассоциирования класса с абстрактным типом.

Пример, приведенный в документе, выглядит следующим образом: он, похоже, не имеет элегантного подкласса:

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;
  }
}

TL; DR сводка других ответов:

• Типы, которые вы распространяете, подвергаются наследуемым типам, но само-типы не являются

  например: class Cow { this: FourStomachs } позволяет использовать методы, доступные только для жвачных животных, например digestGrass. Однако черты, которые расширяют Корову, не будут иметь таких привилегий. С другой стороны, class Cow extends FourStomachs будет выставлять digestGrass всем, кто extends Cow.

• self-types позволяют циклические зависимости, расширяя другие типы, не

Начнем с циклической зависимости.

trait A {
  selfA: B =>
  def fa: Int }

trait B {
  selfB: A =>
  def fb: String }

Однако модульность этого решения не так велика, как может показаться вначале, потому что вы можете переопределить типы типов следующим образом:

trait A1 extends A {
  selfA1: B =>
  override def fb = "B String" }
trait B1 extends B {
  selfB1: A =>
  override def fa = "A String" }
val myObj = new A1 with B1

Хотя, если вы переопределяете член типа self, вы теряете доступ к исходному элементу, к которому все еще можно получить доступ через супер, используя наследование. Итак, что на самом деле достигается за счет использования наследования:

trait AB {
  def fa: String
  def fb: String }
trait A1 extends AB
{ override def fa = "A String" }        
trait B1 extends AB
{ override def fb = "B String" }    
val myObj = new A1 with B1

Теперь я не могу утверждать, что понимаю все тонкости шаблона пирога, но мне кажется, что основным методом обеспечения модульности является использование композиции, а не наследования или типов.

Версия наследования короче, но основная причина, по которой я предпочитаю наследование по типам self, заключается в том, что мне гораздо сложнее получить правильный порядок инициализации с собственными типами. Однако есть некоторые вещи, которые вы можете делать с самими типами, которые вы не можете сделать с наследованием. Типы типов могут использовать тип, тогда как для наследования требуется черта или класс, как в:

trait Outer
{ type T1 }     
trait S1
{ selfS1: Outer#T1 => } //Not possible with inheritance.

Вы даже можете сделать:

trait TypeBuster
{ this: Int with String => }

Хотя вы никогда не сможете его создать. Я не вижу абсолютной причины для того, чтобы не унаследовать от типа, но я уверен, что было бы полезно иметь классы и черты конструктора путей, поскольку у нас есть типы/классы конструктора типов. К сожалению

trait InnerA extends Outer#Inner //Doesn't compile

Мы имеем это:

trait Outer
{ trait Inner }
trait OuterA extends Outer
{ trait InnerA extends Inner }
trait OuterB extends Outer
{ trait InnerB extends Inner }
trait OuterFinal extends OuterA with OuterB
{ val myV = new InnerA with InnerB }

Или это:

  trait Outer
  { trait Inner }     
  trait InnerA
  {this: Outer#Inner =>}
  trait InnerB
  {this: Outer#Inner =>}
  trait OuterFinal extends Outer
  { val myVal = new InnerA with InnerB with Inner }

Один момент, который должен больше сопереживать, заключается в том, что черты могут расширять классы. Спасибо Дэвиду Маклверу за это. Вот пример из моего собственного кода:

class ScnBase extends Frame
abstract class ScnVista[GT <: GeomBase[_ <: TypesD]](geomRI: GT) extends ScnBase with DescripHolder[GT] )
{ val geomR = geomRI }    
trait EditScn[GT <: GeomBase[_ <: ScenTypes]] extends ScnVista[GT]
trait ScnVistaCyl[GT <: GeomBase[_ <: ScenTypes]] extends ScnVista[GT]

ScnBase наследует Swing Класс кадра, поэтому его можно использовать как тип self, а затем смешивать в конце (при создании экземпляра). Тем не менее, val geomR необходимо инициализировать, прежде чем использовать его, наследуя признаки. Поэтому нам нужен класс для принудительной инициализации geomR. Класс ScnVista может затем наследоваться из-за множества ортогональных признаков, которые сами могут быть унаследованы. Использование нескольких параметров типа (generics) предлагает альтернативную форму модульности.

trait A { def x = 1 }
trait B extends A { override def x = super.x * 5 }
trait C1 extends B { override def x = 2 }
trait C2 extends A { this: B => override def x = 2}

// 1.
println((new C1 with B).x) // 2
println((new C2 with B).x) // 10

// 2.
trait X {
  type SomeA <: A
  trait Inner1 { this: SomeA => } // compiles ok
  trait Inner2 extends SomeA {} // doesn't compile
}

Тип "Self" позволяет указать, какие типы разрешены для микширования признака. Например, если у вас есть черта с типом self Closeable, то эта черта знает, что единственное, что разрешено смешивать, должно реализовать интерфейс Closeable.

Обновление: Основное отличие состоит в том, что самонастройки могут зависеть от нескольких классов (я допускаю, что бит-бит). Например, вы можете иметь

class Person {
  //...
  def name: String = "...";
}

class Expense {
  def cost: Int = 123;
}

trait Employee {
  this: Person with Expense =>
  // ...

  def roomNo: Int;

  def officeLabel: String = name + "/" + roomNo;
}

Это позволяет добавить микс Employee только к любому подклассу Person и Expense. Конечно, это имеет смысл только в том случае, если Expense продолжается Person или наоборот. Дело в том, что использование self-types Employee может быть независимым от иерархии классов, от которых он зависит. Он не заботится о том, что расширяет то, что. Если вы переключите иерархию Expense vs Person, вам не нужно изменять Employee.

в первом случае подтип или подкласс класса B можно смешать с любым использованием A. Таким образом, B может быть абстрактным признаком.