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

deprecate DelayedInit outside of App #5479

Closed
scabug opened this Issue Feb 15, 2012 · 10 comments

Comments

Projects
None yet
5 participants
@scabug
Copy link

scabug commented Feb 15, 2012

(No description for SI-5479.)

@scabug

This comment has been minimized.

Copy link

scabug commented Feb 15, 2012

@scabug

This comment has been minimized.

Copy link

scabug commented Oct 29, 2013

@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

This comment has been minimized.

Copy link

scabug commented Jan 28, 2014

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

@scabug

This comment has been minimized.

Copy link

scabug commented Feb 6, 2014

@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

This comment has been minimized.

Copy link

scabug commented Feb 6, 2014

@adriaanm said:
I agree that makes most sense.

@scabug

This comment has been minimized.

Copy link

scabug commented Feb 20, 2014

@MichaelJAllen

This comment has been minimized.

Copy link

MichaelJAllen commented Aug 8, 2017

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

This comment has been minimized.

Copy link
Member

DarkDimius commented Aug 8, 2017

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

@MichaelJAllen

This comment has been minimized.

Copy link

MichaelJAllen commented Aug 9, 2017

@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

This comment has been minimized.

Copy link
Member

SethTisue commented May 17, 2018

@scala scala deleted a comment from scabug May 17, 2018

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