Proposal: use "One More Point" to handle async functions
The traditional callback method to handle async is not elegant and clear. Even the promised style is kind of odd. So I got an idea that we use “One More Point”(OMP) to make async coding easier to use. For example:
So, in general, the OMP makes async coding looks like sync coding. The return value of a function called with OMP will return the value after the “.return” keyword. The code after the OMP call will all be delayed until the async ends. This sounds like the code is blocked, but actually it’s non-blocking, as the user can still interact with the interface and the cpu is sleeping. There is one limitation that OMP style can only replace callback style async calls that are at the end of a function, since there is no more code after the async function is called. However, as far as I can see, about half or more async functions are at the end of a function. So, the OMP is significant.
Re: Proposal: use "One More Point" to handle async functions
What you call "one more point" already exists as the `await` keyword and
is much more powerful than a limited `.return` operator:
Please make sure to be familiar with the topic before making further
>That’s not necessarily true — `await` in modules may be very different from this.
I don’t know what await in modules look like.
It’s still being discussed. I think there are some strong arguments for top-level “await”, which is the only case where you’re (currently) forced to be in a synchronous mode.
>You might be confused about something — if an awaited Promise is rejected, the async function can be resumed from a catch block to handle the rejection.
I know await can be catched. But the redundant reject state in promise makes it more confusing.
What “redundant reject state”? What is redundant? And more importantly, how is it confusing? It maps to the same syntax of typical synchronous code, which is pretty clear about the error state vs non-error state.
>I’m not sure everyone shares this view — many people laud other languages where coroutines (for example) are indistinguishable from regular subroutines.
Well, when you are debugging and can’t find where the code waits, you’ll miss the OMP.
That sounds like a puzzle for the DevTools team to solve :) There’s no reason the inspector couldn’t see this.
I thought it again. Can I write: ‘await obj2.doSomeOtherThing(await obj1.doSomeThing())’? If I can, then the await is not more complex than OMP when dealing with deep async, just a little longer.
Yes, AwaitExpressions are just a form of UnaryExpression, and can be used anywhere a UnaryExpression is used (including as an operand to a function which is being `await`-ed.
3: the async function calls identically with sync functions, makes it hard to check out if the function is async without jumping to the definition. But OMP can easily be recognized.
Usually, async calls will be marked with `await`, which to me seems somewhat easier to spot.
On the other hand it's true that the function call itself is just a function call. One nice consequence is that you can call an async function without immediately blocking and waiting for it to finish. For example,
let p1 = start_download(); // start two things at once
let p2 = start_query(); let file = await p1; // wait for results
let result = await p2;
Is that possible with OMP syntax?
In your proposal, what would happen if you called an OMP async function (one that ends with a `.return`) using `plain.method()` call syntax? What if you call a sync function or method using OMP call syntax?