deprecate DelayedInit outside of App

[scabug]

(No description for SI-5479.)

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-5479?orig=1
Reporter: @adriaanm

[scabug]

@retronym said:
Marking as "fixed" because DelayedInit was shipped in 2.10.0.

I think it is unlikely we will spec its semantics post-factum; if anything we should deprecated its use outside of App as it is full of holes.

[scabug]

@adriaanm said:
should we plan on supporting top-level defs to replace App in 2.12?

[scabug]

@gkossakowski said:
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.

[scabug]

@adriaanm said:
I agree that makes most sense.

[scabug]

@adriaanm said:
scala/scala#3563

[Facsimiler]

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]

@MichaelJAllen, I don't have experience with ScalaFX, but in our experience in Dotty we were able to convert all the usages of DelayedInit into constructor arguments.

In the example that you've referred to, could you make stage be constructor argument of JFXApp? This will run the code during class initialization, similar to how it's currently done with DelayedInit.

The main difference would be that it will not introduce duplicated members & scopes automagically.

[Facsimiler]

@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.

[SethTisue]

new discussion at https://contributors.scala-lang.org/t/scala-3-delayedinit/1902