DelayedInit traits aren't rewritten #5199
Comments
|
Imported From: https://issues.scala-lang.org/browse/SI-5199?orig=1 |
|
@paulbutcher said: Delayed Initializaton. The initialization code of an object or class (but not a trait) that follows the superclass constructor invocation and the mixin-evaluation of the template’s base classes is passed to a special hook, which is inaccessible from user code. Normally, that hook simply executes the code that is passed to it. But templates inheriting the scala.DelayedInit trait can override the hook by re-implementing the delayedInit method But:
So at a minimum this is a bug in the documentation - but it would be much clearer if traits were rewritten too? |
|
@heathermiller said: And you're right, this is spec'ed and not a bug. I suggest opening up a discussion on scala-internals for related questions/suggestions. |
The following code:
trait T1 { this: App =>
println("arguments in T1: "+ args)
}
trait T2 { this: App =>
delayedInit {
println("arguments in T2: "+ args)
}
}
trait T3 extends DelayedInit { this: App =>
println("arguments in T3: "+ args)
}
object Main extends App with T1 with T2 with T3 {
println("arguments in Main: "+ args)
}
generates the following output:
arguments in T1: null
arguments in T3: null
arguments in T2: [Ljava.lang.String;@7bccf12f
arguments in Main: [Ljava.lang.String;@7bccf12f
I understand why T1 gives null and why T2 gives non-null. But I'm confused by T3. The DelayedInit documentation says:
Classes and traits inheriting the
DelayedInitmarker trait will have their initialization code rewritten as follows.becomes delayedInit()Note that it explicitly says that traits are rewritten, so I would expect that T3 would work just like T2?
The text was updated successfully, but these errors were encountered: