-
Notifications
You must be signed in to change notification settings - Fork 57
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
Promise / Callback Types (Instead of async/await?) #146
Comments
I have very limited experience writing async code. I know Node.js heavily relies on it, but is it also used in browser JS ? It took C# a decade to incorporate it and Java still doesn't have |
I'm not suggesting we do async/await. I'm suggesting we support asynchronous callbacks (eg. Promise, Future, Task) - which predate async/await style keywords significantly. Java does have similar concepts (CompletableFuture) and C++ too (std::future) In JS/TS, yes of course - async callbacks is even more important in the browser. Asynchronous code in the browser dates back to the very beginning of javascript. Pretty much everything you did had to be interrupted and continued at some point later with a callback (think waiting for user input, waiting for an HTTP request to complete, waiting for an animation to play, etc etc etc). In other languages, it's probably not quite as important (in JS it's an absolute requirement as a library author). However every language will have a similar concept to a Promise, and if it doesn't, a simple abstraction can be added on top of pure callbacks, which is why I suggest that this depends on #144. The reasons above are also why when we start writing API's like "CopyFile", "HttpRequest" and so forth, we need to support and expose asynchronous functions in Fusion... otherwise it will never be possible to use Fusion as a library for JS in a practical sense because of it's singlethreaded nature. |
Thank you! Last time I did any significant browser JS was a dozen years ago: validation, DOM manipulations and AJAX. No |
I think this depends on #144.
It's a very common library paradigm to provide asynchronous functions. In JS, it's not even possible to wait synchronously on a promise, so if directly using an asynchronous API in a
native { }
block, this can not be propagated up to a consumer of the library. It's also not possible to start a new thread to run a synchronous function in the background - so it's particularly important in that environment.I suggest a simple implementation (when compared with an async/await state machine).
Also I'll note, #144 is a good step in the right direction, but falls short because it doesn't allow the consumer to easily block synchronously on the result.
The first step would be allowing the
Task<T>
type to be returned from methods. Translated into language-specific "Promise" types.Task
but notTask<T>
, and returning some kind of wait handle?std::future
Task<T>
Promise<T>
CompletableFuture<T>
The second step would be some way to create and complete tasks:
The proposed API would allow Fusion authors to fully utilise and expose native asynchronous functionality initially, and later on, presumably, the Fusion standard lib will also expose some asynchronous functions.
Some examples:
The text was updated successfully, but these errors were encountered: