What about just having compiler magic specifically for App and not try to come up with general mechanism? We could even spec the compiler magic.
I know that this is against Scala's spirit but let's face it: App is a very small feature that is mostly important to people learning and teaching Scala. Let's just deliver this feature in the most useful way to Scala users and move on to more important issues.
Just to be clear, I understand why DelayedInit is deprecated, and I'm certainly not attempting to reopen this issue or to have the decision overturned.
However, in ScalaFX, the JFXApp trait currently relies heavily upon DelayedInit. The reason is that JFXApp subclasses need to run their initialization/constructor code on the JavaFX application thread - it's impossible to interact with JavaFX otherwise. The same trait is responsible for initializing JavaFX and creating that thread too. (Refer to the ScalaFX site for some code examples that will illustrate my point better.) DelayedInit makes this trivial and elegant (barring those issues which have made deprecation desirable).
It seems that there are no plans for a replacement feature that works better. I've seen the proposal to use an onCreate event (issue #4330) to replace some uses of DelayedInit, but that isn't such an elegant solution for our particular case (and it doesn't exist as yet either, so far as I can tell). So we're likely faced with some major refactoring decisions going forward.
I think the most obvious solution is to split JFXApp into two classes, one that creates the application and initializes JavaFX, and another (executed on the JavaFX application thread) that is a base class for defining the GUI and its interactions. However, it's not clear to me how we could make this compatible with existing code.
Does anyone have any suggestions for an elegant DelayedInit workaround that doesn't break existing code?
@DarkDimius Thanks for your suggestion! It was the removal of support for DelayedInit from Dotty that got me thinking about this issue - and I very much like what I've seen of DOT and Dotty so far...
I think I see what you're getting at. You pass a function containing the GUI configuration during initialialization to JFXApp, which is then set aside until after JavaFX is initialized and its application thread created. The GUI config function is then scheduled for execution on the JFX application thread. Is that right? (BTW, I've generalized this, since it's not just the stage that's initialized - lots of other GUI elements can be initialized too.)
I guess I'll need to think about this some more and try it out, but if I have your concept right, this would break existing code in a number of ways, and it seems that the scoping would complicate matters a lot too.