New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DelayedInit traits aren't rewritten #5199

Closed
scabug opened this Issue Nov 17, 2011 · 3 comments

Comments

Projects
None yet
1 participant
@scabug
Copy link

scabug commented Nov 17, 2011

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?

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Nov 17, 2011

Imported From: https://issues.scala-lang.org/browse/SI-5199?orig=1
Reporter: @paulbutcher
Affected Versions: 2.9.1

@scabug

This comment has been minimized.

Copy link
Author

scabug commented Nov 17, 2011

@paulbutcher said:
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

But:

  • it's not clear to me why traits are excluded
  • it's inconsistent with the DelayedInit documentation

So at a minimum this is a bug in the documentation - but it would be much clearer if traits were rewritten too?

@scabug

This comment has been minimized.

Copy link
Author

scabug commented May 7, 2012

@heathermiller said:
Fixed the inconsistency in the API docs: pull request

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.

@scabug scabug closed this May 7, 2012

@scabug scabug added the delayedinit label Apr 7, 2017

@scabug scabug added this to the 2.10.0-M3 milestone Apr 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment