About me:

• https://github.com/darkdimius/
• doing PhD at EPFL
• previously worked on ScalaBlitz (up to 24x faster collections)
• since March 2014 building on Dotty under supervision of Martin.
• since March 2015 working on Dotty Linker and supervising students working on Dotty.

Dotty contributor stats:

Background: Java

• Classes
• Interfaces
  • no fields
  • no statements in the body(no constructors)
• Single inheritance of classes

Only classes have initialization statements.

They get executed in the order they are written.

object helper {
  def init(name: String) = {println(name)}
}
import helper._

class A {
  val a = {init("A.a"); 1}
}

class B extends A {
  val b = {init("B.b"); 1}
}

A.a
B.b

Scala

• Classes
• Traits
  • may have fields
  • may have statements in the body
• Multiple inheritance of traits

Multiple inheritance of initialization code.

Order of execution matters

Simple examples

trait A {
  val a = { init("A.a"); 1}
}

trait B {
  val b = { init("B.b"); 2}
}

class AB extends A with B {}

A.a
B.b

trait A {
  val a = { init("A.a"); 1}
}

trait B {
  val b = { init("B.b"); 2}
}

class AB extends B with A {}

B.b
A.b

trait A {
  val a = { init("A.a"); 1}
}

trait B extends A {
  val b = { init("B.b"); 2}
}

class AB extends A with B {}

A.a
B.b

trait A {
  val a = { init("A.a"); 1}
}

trait B extends A {
  val b = { init("B.b"); 2}
}

class AB extends B with A {}

A.a
B.b

Tricky examples

trait A {
  val a = { init("A.a"); 1}
 }

trait B extends A {
  println(a + " " + b)
  val b = { init("B.b"); 2}
}

class AB extends B with A {}

A.a
1 0
B.b

trait A {
  val a = { init("A.a"); 1}
 }

trait B extends A {
  val b = { init("B.b"); 2}
  println(a + " " + b)
}

class AB extends B with A {}

A.a
B.b
1 2

trait A {
  val a = { init("A.a"); 1}
}

trait B extends A{
  val b = { init("B.b"); 2}
  println(a + " " + b)
}

class AB extends B {
  override val b = {init("AB.b"); 3}
}

A.a
B.b
1 0
AB.b

trait A {
  val a = { init("A.a"); 1}
}

trait B extends A{
  val b = { init("B.b"); 2}
  println(a + " " + b)
}

class AB extends B {
  override final val b = 3
}

A.a
B.b
1 3

How it works?

Specification: Linearization order

Implementation:

• Getters
• Constructors
• Trait setters
• Trait initializers

Getters

val s = 1

is desugared into

private val s$private = 1
def s = s$private

Constructors

trait A {
 <statements1>
 val field1 = <expr1>
 <statements2>
 val field2 = <expr2>
 ....
}

is transformed into

intefrace A {
 final val field1
 final val field2
 def <init> = {
   <statements1>
   field1 = <expr1>
   <statements2>
   field2 = <expr2>
   ...
  }
}

Wait... Fields?

In an interface?

Does not work

Trait setters

Scalac would have instead:

intefrace A {
 def A$field1$setter(value)
 def A$field2$setter(value)
 def <init> = {
   <statements1>
   A$field1$setter(<expr1>)
   <statements2>
   A$field2$setter(<expr2>)
   ...
  }
}

Implementing class

• has to call the methods in order defined by linearization
• has to implement trait setters
• may need to forward some methods
  • this is why collections have classes such as AbstractTraversable

class Implementation extends A {
  private A$field1 = _
  def A$field1_setter(value) = {A$field1 = value}
  private A$field2 = _
  def A$field2_setter(value) = {A$field2 = value}
  def <init> = {
    super[A].<init>
  }
}

why it's bad?

fields are no longer final

Dotty would have instead:

intefrace A {
  def A$field1$initial = {
    <statements1>
    <expr1>
  }
  def A$field2$initial = {
    <statements2>
    <expr2>
   }
}

class Implementation extends A {
  private final A$field1 = _
  private final A$field2 = _
  def <init> = {
    A$field1 = A$field1$initial
    A$field2 = A$field2$initial
  }
}

Going back to example

trait A {
  val a = { init("A.a"); 1}
 }

trait B extends A {
  val b = { init("B.b"); 2}
  println(a + " " + b)
}

class AB extends B with A {}

A.a
B.b
1 2

trait A {
  val a = { init("A.a"); 1}
 }

trait B extends A {
  println(a + " " + b)
  val b = { init("B.b"); 2}
}

class AB extends B with A {}

A.a
1 0
B.b

trait A {
  val a = { init("A.a"); 1}
}

trait B extends A{
  val b = { init("B.b"); 2}
  println(a + " " + b)
}

class AB extends B {
  override val b = {init("AB.b"); 3}
}

A.a
B.b
1 0
AB.b

trait A {
  val a = { init("A.a"); 1}
}

trait B extends A{
  val b = { init("B.b"); 2}
  println(a + " " + b)
}

class AB extends B {
  override final val b = 3
}

A.a
B.b
1 3

Current alternatives: lazy vals

trait Greeting {
  val name: String
  val msg = "How are you, " + name
}
class C extends Greeting {
  lazy val name = "Bob"
  println(msg)
}

Initialization on demand.

Every access needs to pay a price: synchronize and check that field is initialized.

May cause deadlocks. For details, see my ScalaWorld2015 presentation.

Future: Dotty

Lazy vals do not cause spurious deadlocks.

Has both thread-safe and thread-unsafe lazy vals.

Alternative: early definitions

On JVM, before calling superconstructor the only thing you can do is to assign&read fields.

trait Greeting {
  val name: String
  val msg = "How are you, " + name
}
class C extends {
  val name = "Bob"
} with Greeting {
  println(msg)
}

Spec says: Early definitions are particularly useful for traits, which do not have normal constructor parameters.

In Dotty: SIP 25

Trait Parameters

trait Greeting(val name: String) {
  val msg = "How are you, " + name
}
class C extends Greeting("Bob") {
  println(msg)
}

Does not solve the problem of accessing partially or not initialized fields.

A crazy idea

Make val fields behave as if they were lazy during constructor only.

Takeaway

• Don't override vals, unless you really have to;
• Don't use early definitions, unless you really have to;
• Trait constructors are to come and solve it in future;
• In case code is not pefrormance-critical, consider using lazy vals.

Thank you

See my other talks.

Q&A