Rewriting tool should warn on extending DelayedInit

[DarkDimius]

Out of 1500 run tests that fail, 900 fail due to them extending scala.App, which relies on DelayedInit, that is not supported.

[DarkDimius]

ping @samuelgruetter

[densh]

@odersky is there a plan to completely remove DelayedInit in the future?

[odersky]

Yes, we should remove delayedInit.

But given the 900 test failures I think it would be reasonable if the
rewriting tool rewrote
"extends App" instead of just issuing a warning. I.e.

object Foo extends App { ... }

becomes

object Foo extends App { override def main(args: Array[String]): Unit =

{ ... }}

If we have macro annotations, we could envision having syntactic sugar like

@app object Foo { ... }

for this. App can be left as a convenience class in dotty, but it would not
have a delayedInit mechanism. More or less all it would do is make the
command line arguments available.

• Martin

On Wed, May 13, 2015 at 1:16 PM, Denys Shabalin notifications@github.com
wrote:

@odersky https://github.com/odersky is there a plan to completely
remove DelayedInit in the future?

—
Reply to this email directly or view it on GitHub
#559 (comment).

Martin Odersky
EPFL

[DarkDimius]

@odersky For tests, I've added an superclass that has a main method: dotty-staging@28bb276 dotty-staging@28bb276

This is almost equivalent to moving statements into the body of class, the only difference is that tests are actually now executed before main method is called.
This made several hundred tests pass.

[densh]

@app object Foo { ... } looks like a really cool replacement.

[DarkDimius]

Honestly, I dislike the app being so short. In most cases, there are have no-more than two main methods in project. I'd prefer to be explicit here, and write the full @application, as it is easier to read.

[He-Pin]

I like @application too.

[odersky]

@Application / @app, either is fine with me.

On Wed, May 13, 2015 at 2:32 PM, kerr notifications@github.com wrote:

I like @Application too.

—
Reply to this email directly or view it on GitHub
#559 (comment).

Martin Odersky
EPFL

[densh]

Lets create wiki page that lists all of the expected incompatibilities starting with this one. (Unfortunately I don't have the permission to do this.)

[samuelgruetter]

@densh the list of incompatibilities is currently maintained as a bullet-point list in the readme of the rewrite tool.

So Dmitry's LegacyApp makes the run tests work, but in the future, how should the rewrite tool handle App and DelayedInit?
If App is left as a convenience class in dotty, as Martin suggested, no rewriting will be done for App. So the rewrite tool would only have to warn if DelayedInit is used. But on the other hand, this will also be reported once you try to compile the code with dotty. So this leads to the question if the rewrite tool should warn about library incompatibilities at all, or just focus on the rewriting?

[DarkDimius]

If App is left as a convenience class in dotty, as Martin suggested, no rewriting will be done for App.

App class itself relies on DelayedInit functionality.
While I was able to make run tests work with LegacyApp, this is because none of tests inspects command line arguments.
Other App classes could actually inspect arguments, and I see no non-magical way which can simulate old behavior.

[retronym]

Bikeshedding a little::

object Test1 {
  def main = {
  }
}

And have scala add a main-method bridge. If you want the arguments, write the full main method. Or allow the slightly less jarring signature (as in Java);

object Test2 {
  def main(args: String*) = {
  }
}

I prefer this over @app to avoid perpetuating confusion when people write:

@app object Test {
  val x = 42
}

object Test2 {
   def main(a: Array[String]) = {
     Test.x // null under Scala 2(with a warning). Maybe this wouldn't compile under the macro annotation version?
   } 
}

[retronym]

While I've got the paint out, here's another colour:

@app class C { println("foo") }
@app class D(args: String*) { println(args.length) }

class C { println("foo"); <static> def main(args: Array[String]) = new C() }
class D(args: String*) { println(args.length); <static> def main(args: Array[String]) = new C(WrappedArray(args))  }