Details

      Description

      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.
      <code> becomes delayedInit(<code>)

      Note that it explicitly says that traits are rewritten, so I would expect that T3 would work just like T2?

        Activity

        Hide
        Paul Butcher added a comment -

        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?

        Show
        Paul Butcher added a comment - 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?
        Hide
        Heather Miller added a comment -

        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.

        Show
        Heather Miller added a comment - 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.

          People

          • Assignee:
            Unassigned
            Reporter:
            Paul Butcher
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development