DelayedInit fails for top derived class has empty constructor

[scabug]

Consider the code:

trait A extends DelayedInit {
  println("A ConstructionCode")

  def delayedInit(body: => Unit) = {
    body
    postConstructionCode
  }
  protected def postConstructionCode: Unit = {
    println("A PostConstructionCode")
  }
}
trait B extends A {
  println("B ConstructionCode")
  override protected def postConstructionCode: Unit = {
    super.postConstructionCode
    println("B PostConstructionCode")
  }
}

trait C extends B {
  println("C ConstructionCode")
  override protected def postConstructionCode: Unit = {
    super.postConstructionCode
    println("C PostConstructionCode")
  }
}
object Test {
  def main(args: Array[String]) {
    val c = new C {}
  }
}

This produces the output:

A ConstructionCode
B ConstructionCode
C ConstructionCode

But when the constructed "C" has a non-empty constructor, such as:

    val c = new C { println("New C ConstructionCode") }

Then the DelayedInit works and generates:

A ConstructionCode
B ConstructionCode
C ConstructionCode
New C ConstructionCode
A PostConstructionCode
B PostConstructionCode
C PostConstructionCode

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-4680?orig=1
Reporter: Richard Emberson (rmemberson)
Affected Versions: 2.9.1

[scabug]

Commit Message Bot (anonymous) said:
(extempore in r25067) A test case demonstrating some of the issues with DelayedInit.
References #4680. Review by odersky.

[scabug]

@paulp said:
Raising the priority over the issues in the linked test case.

[scabug]

@odersky said:
I think we'll get back to delayedInit once macros are a bit more mature. Demoting from critical to major.

[scabug]

Matt Hicks (darkfrog) said:
Please come back and fix this. There's so much that DelayedInit makes possible but in its current state it's completely unusable.

[scabug]

@paulp said:
I'm sure in martin's head DelayedInit is specified in spectacular detail; unfortunately in real life it is not, and I couldn't fix it if I wanted to because I don't know what it is supposed to do.

[scabug]

Matt Hicks (darkfrog) said:
Paul, the concept is fairly simple. It allows the body / constructor of the class to be invoked explicitly within the delayedInit method receiving the "body" function that contains body of the class. This allows things to happen before or after the initialization of the class. This is of particular interest as it allows a class that is sub-classed to execute functionality post-construction of the instance. To my knowledge there is no other way to accomplish this in Java or Scala without DelayedInit.

[scabug]

@paulp said:
It isn't the concept which needs documenting, it is the specification. For starters, please document exactly what should be the output of this:

https://raw.github.com/scala/scala/c8f4316b3/test/files/run/bug4680.scala

Here is what it produced at the time of its writing and presumably at present:

https://raw.github.com/scala/scala/c8f4316b3/test/files/run/bug4680.check

[scabug]

@paulp said:
Based on what you say you want, you would be better off with the alternative, which is also what I want, which I implemented and which was dismissed.

https://groups.google.com/forum/#!topic/scala-debate/5nbzkiv6lFI

[scabug]

Matt Hicks (darkfrog) said:
This is one of the bugs with DelayedInit. The first instantiation of C should have the same output as the second instantiation of C and similarly for the others.

I'm all for your alternative if we could get it introduced, but as it is DelayedInit exists now but requires bug-fixes...a new feature to the language I find doubtful at least in 2.10. I think it's reasonable for DelayedInit to be fixed before you can consider 2.10 to be out of RC considering this is a glaring bug that needs to be fixed.

[scabug]

@paulp said:
It is not even a remote possibility this will be fixed for 2.10.0. You should probably set your sights on "ever".

[scabug]

@adriaanm said:
I agree with Paul. 2.10.0 is extremely nigh to final (as in, RC3 is closed and will hopefully become 2.10.0).

DelayedInit is unfortunately plagued with issues -- it seems to be common theme with these main-method replacements.
Maybe we should reconsider DelayedInit altogether, but that's a >= 2.11 thing.

In the meantime, yes, DelayedInit bugs should be fixed in 2.10.x

[scabug]

Matt Hicks (darkfrog) said:
Is there any other way to accomplish post-constructor functionality in Scala today without DelayedInit? I would be fine with Paul's alternative suggestion if that will get us where we need to be and then you could throw away DelayedInit for all I care. I'm sure I could use ASM to accomplish what I want, but that would require runtime bytecode manipulation and I'd like to avoid that.

[scabug]

@paulp said:
"Is there any other way to accomplish post-constructor functionality in Scala today without DelayedInit?"

Nope. I have another unpublished branch which comes at it from another angle; you can define postInit in the companion of any class, and after instantiation it traverses all the base classes calling any companion-defined postInit methods with the newly created instance as the argument. This makes it possible to inherit from a class, write custom postInit code, yet still have the base class's postInit code called, without being required to know about and dispatch to the existing postInits.

The major weakness is that it of necessity depends on the participation of the compiler; it would all break down if any such class were instantiated from java. This might not matter to most people, but it would be an issue nonetheless. (You could make the constructors private, but then you lose the part where you can still use inheritance.)

[scabug]

@adriaanm said:
Un-assigning to foster work stealing, as announced in https://groups.google.com/forum/?fromgroups=#!topic/scala-internals/o8WG4plpNkw