Scala: constructor orders in inheritance - scala

Question

Can someone explain me in detail about orders in which constructors are called in inheritance in scala please? Say I have:
abstract class A {
private var data: T = compute()
protected def compute(): T
}
class ImpA extends A {
var a = 0
override def compute() {
a = 1
null.asInstanceOf[T] // doesn't matter
}
}
val inst = new ImpA
Then it appears that inst.a == 0, so I guess that what happens is that when ImpA's constructor is called then, A constructor is called also, which actually triggers compute() that should set a = 1. But then scala goes back down to ImpA's constructor and reset a = 0. Is that it?
Is there some well-known pattern to avoid this properly? (I'm not really trying to fix this problem that can be easily dealt with, though if there are patterns that are advised I'm eager to know them; but I'd rather like to have a deep understanding of what's happening, and hopefully know why reinitializing the variable a could be interested in that case. And also what would happen internally if it was a val as it would lead to assign several references to the same variables if the logic is kept...).
Thanks in advance.
EDIT: something fun also is when you just change ImpA.a and use a reference instead of a var:
class ImpA extends A {
class B {
var b = 0
}
val b = new B
override def compute() {
b.b += 1
null.asInstanceOf[T] // doesn't matter
}
}
then it throws a java.lang.NullPointerException because b isn't instantiated yet. Following Yuval Itzchakov solution, here's what it compiles into:
abstract class A extends Object {
private[this] var data: Object = _;
<accessor> private def data(): Object = A.this.data;
<accessor> private def data_=(x$1: Object): Unit = A.this.data = x$1;
protected def compute(): Object;
def <init>(): test.A = {
A.super.<init>();
A.this.data = A.this.compute();
()
}
};
class ImpA extends test.A {
private[this] val b: test.ImpA$B = _;
<stable> <accessor> def b(): test.ImpA$B = ImpA.this.b;
override def compute(): Unit = {
ImpA.this.b().b_=(ImpA.this.b().b().+(1));
{
(null: Object);
()
}
};
override <bridge> <artifact> def compute(): Object = {
ImpA.this.compute();
scala.runtime.BoxedUnit.UNIT
};
def <init>(): test.ImpA = {
ImpA.super.<init>();
ImpA.this.b = new test.ImpA$B(ImpA.this);
()
}
};
class ImpA$B extends Object {
private[this] var b: Int = _;
<accessor> def b(): Int = ImpA$B.this.b;
<accessor> def b_=(x$1: Int): Unit = ImpA$B.this.b = x$1;
<synthetic> <paramaccessor> <artifact> protected val $outer: test.ImpA = _;
<synthetic> <stable> <artifact> def $outer(): test.ImpA = ImpA$B.this.$outer;
def <init>($outer: test.ImpA): test.ImpA$B = {
if ($outer.eq(null))
throw null
else
ImpA$B.this.$outer = $outer;
ImpA$B.super.<init>();
ImpA$B.this.b = 0;
()
}
}
Though it's a bit harder to understand properly, it explains quite straightforwardly why the NullPointerException is thrown.
But if you use this time a lazy val b = new B, then it works:
class ImpA extends test.A {
#volatile private[this] var bitmap$0: Boolean = false;
private def b$lzycompute(): test.ImpA$B = {
{
ImpA.this.synchronized({
if (ImpA.this.bitmap$0.unary_!())
{
ImpA.this.b = new test.ImpA$B(ImpA.this);
ImpA.this.bitmap$0 = true;
()
};
scala.runtime.BoxedUnit.UNIT
});
()
};
ImpA.this.b
};
lazy private[this] var b: test.ImpA$B = _;
<stable> <accessor> lazy def b(): test.ImpA$B = if (ImpA.this.bitmap$0.unary_!())
ImpA.this.b$lzycompute()
else
ImpA.this.b;
override def compute(): Unit = {
ImpA.this.b().b_=(ImpA.this.b().b().+(1));
{
(null: Object);
()
}
};
override <bridge> <artifact> def compute(): Object = {
ImpA.this.compute();
scala.runtime.BoxedUnit.UNIT
};
def <init>(): test.ImpA = {
ImpA.super.<init>();
()
}
};

Answer 1

Let's see what the compiler generates when compiling (using the -Xprint:jvm flag):
class ImpA extends com.testing.A {
private[this] var a: Int = _;
<accessor> def a(): Int = ImpA.this.a;
<accessor> def a_=(x$1: Int): Unit = ImpA.this.a = x$1;
override def compute(): String = {
ImpA.this.a_=(1);
(null: String)
};
override <bridge> <artifact> def compute(): Object = ImpA.this.compute();
def <init>(): com.testing.ImpA = {
ImpA.super.<init>();
ImpA.this.a = 0;
()
}
};
What do we see? We see that the constructor running for ImplA (defined as the <init> method) first calls ImpA.super.<init>(), which is a call to A to initialize itself first. As initialization code looks like this:
def <init>(): com.testing.A = {
A.super.<init>();
A.this.data = A.this.compute();
()
}
It calls A.super, which is Object, and then calls A.this.compute(). This method initializes a to hold the value 1. Once that initialization finishes, ImplA sets a to 0, as you told it to do during constructor initialization. That is why you're seeing the value 0 for a.
To sum up, the execution flow is as follows:
ImplA calls As init method
A calls compute, which is invoked on ImplA
ImplA.compute assigns a the value 1
ImplA assigns a the value 0
For more, see http://docs.scala-lang.org/tutorials/FAQ/initialization-order.html