- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
DelayedInit inconsistency?
Sat, 2011-11-12, 15:19
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 `DelayedInit` marker 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 SLS gives a hint as to what's going on:
> 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
Why are traits excluded?
--
paul.butcher->msgCount++
Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?
http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher
Tue, 2011-11-15, 13:27
#2
Re: DelayedInit inconsistency?
On Tue, Nov 15, 2011 at 12:26 PM, Paul Butcher <paul@paulbutcher.com> wrote:
Hi Paul,
Is your issued covered by #SI-4860? The corresponding test case [1] shows quite a few problems.
-jason
[1] https://issues.scala-lang.org/browse/SI-4680[2] https://codereview.scala-lang.org/fisheye/changelog/scala-svn?cs=25067
Having received no replies, I'm wondering if this is the right mailing list for this kind of thing? I thought that it would be more appropriate than scala-user or scala-debate - perhaps I was mistaken, however?
I believe that this is a bug - but I'm unsure whether it's a bug in DelayedInit's documentation or its implementation?
Hi Paul,
Is your issued covered by #SI-4860? The corresponding test case [1] shows quite a few problems.
-jason
[1] https://issues.scala-lang.org/browse/SI-4680[2] https://codereview.scala-lang.org/fisheye/changelog/scala-svn?cs=25067
Tue, 2011-11-15, 13:47
#3
Re: DelayedInit inconsistency?
On 15 Nov 2011, at 12:19, Jason Zaugg wrote:
> Is your issued covered by #SI-4860? The corresponding test case [1] shows quite a few problems.
I don't think so, no. If I'm reading it correctly, #SI-4860 relates to problems that occur if a trait has an explicit delayedInit method, but the concrete class that the trait is mixed into has an empty constructor.
The problem that I've encountered is that the body of a trait that extends DelayedInit, but does not have an explicit delayedInit method, is not rewritten to use delayedInit (which appears to be contrary to the DelayedInit documentation).
--
paul.butcher->msgCount++
Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?
http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher
Having received no replies, I'm wondering if this is the right mailing list for this kind of thing? I thought that it would be more appropriate than scala-user or scala-debate - perhaps I was mistaken, however?
I believe that this is a bug - but I'm unsure whether it's a bug in DelayedInit's documentation or its implementation?
On 12 Nov 2011, at 14:19, Paul Butcher wrote:
> 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 `DelayedInit` marker 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 SLS gives a hint as to what's going on:
>
>> 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
>
>
> Why are traits excluded?
>
> --
> paul.butcher->msgCount++
>
> Snetterton, Castle Combe, Cadwell Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> MSN: paul@paulbutcher.com
> AIM: paulrabutcher
> Skype: paulrabutcher
>
--
paul.butcher->msgCount++
Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?
http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul@paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher