Jens, my suggestion was to propagate the asyncs up the call stack to all callers of the function, automatically changing each one to return a promise, and use await on the calls to the async functions, which would work fine except for losing the atomic synchonization of the functions effects in JS, relative to other events
I see, yeah ok that might work however I think it would instantly break your code assumptions because of state modifications.
The reason is that the code that schedules an asynchronous task is synchronous in itself. So if you have a long call stack and at the bottom you schedule an XMLHttpRequest then everything is still executed synchronously, only the result of the request comes in asynchronously and only the code that runs when retrieving the result executes asynchronously.
If you now rewrite that to async / await and propagate it through the call stack then you have lots of await keywords in your call stack now and at all those locations suddenly other code can execute. So when looking at your Java code from a higher level you can never be sure if two lines of code within the same method body execute synchronously or not.
-- J.
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment