Hey Florian,
Why do we even need to do that?
async function someAsync() { something(() => { return "hello"; }); } let d =
function() { return await someAsync(); } let c = function() { return d(); }
Because `d()` is no longer an asynchronous function, you can call it like
normal, surely?
On 26/02/2017 12:44:01, Florian Bösch <[email protected]> wrote:
It would be nice if there even was an argument, but there isn't. There isn't
because async/await naturally devolves into implicit coroutines, so any
argument would be moot.
To illustrate, suppose you have these 4 functions:
let a = function(){
return b();
}
let b = function(){
return c();
}
let c = function(){
return d();
}
let d = function(){
return whatever();
}
Call chains like this are typical. It's the staple of software engineering (for
reasons of proper separation of concerns, reuse of utility code, etc.). If you
believe that there is an argument about this being exemplary, it would be
impossible to have an argument with you about software engineering at all. Of
course real-world examples are more complex and don't just return whatever the
underlying function produced, but as a control flow example it suffices. These
chains are often much deeper than 4 levels, it's not uncommon to encounter call
chains 10, 15, 20 or 30 layers deep.
Now let's suppose you figure that function d wants to do something asynchronous.
So you go and do:
let d = function(){
return xhr();
}
But of course that doesn't work, because d is not async. So you go and do:
let d = async function(){
return await xhr();
}
Of course that doesn't work because c is not async, and so forth, so eventually
your code looks like that.
let a = async function(){
return await b();
}
let b = async function(){
return await c();
}
let c = async function(){
return await d();
}
let d = async function(){
return await xhr();
}
In essence, you've applied to following two regular expression:
s/function/await function/g and s/.+?\(\)/await ()/ . Of course that'd be
horrid to do, so in reality you'd please use a proper JS parser. How did your
code look before you applied these regular expressions? Well, it looks exactly
like at the start.
let a = function(){
return b();
}
let b = function(){
return c();
}
let c = function(){
return d();
}
let d = function(){
return xhr();
}
But it isn't like at the start, because now it can trigger race conditions and
is asynchronous. It is in fact now idempotent with true co-routines, except
some unnecessary code transmoglification.
This conclusively proves that await/async is an inconvenient clutch that
naturally devolves into true co-routines. Now you might try to argue, that
real-world code isn't just going to prefix every function call with await and
every function body with async and stay that way.
However, this would be in invalid argument for actual real-world code, because.
People don't just constantly switch back and forth and re-engineer their code
just because they want something async to happen underneath. You don't go and
bicycle repair every call and function definition if you should decide to
toggle synchronous or asynchronous. Therefore, since prefixing everything works
no matter if it is asynchronous or synchronous, you will stay with the prefixes
once you've added them. Which not only guarantees that async/await devolves
into true co-routines, but it also gurantees that they proliferate everything
and once they're in, they're never going out.
And that's why it isn't an argument.
On Sun, Feb 26, 2017 at 12:05 PM, Alexander Jones <[email protected]
[mailto:[email protected]]> wrote:
Florian, you shouldn't pass the argument of explicit vs implicit coroutines off
as being so simple. There are many compelling arguments for both! Please Google
them!
On Sun, 26 Feb 2017 at 00:01, Florian Bösch <[email protected]
[mailto:[email protected]]> wrote:
On Sat, Feb 25, 2017 at 11:55 PM, Codefined <[email protected]
[mailto:[email protected]]> wrote:
This seems to be so very confusing for anybody new studying this language,
almost everyone I talk to gets stuck up on some part of it.
Promises are bad, and mixing them with async/await is worse. Should never have
been added to any kind of standard.
async function asyncFunction() { let [err, data] = await asyncFunction() }
function asyncFunction(){
return otherAsyncFunction();
}
Even simpler, you'd just need co-routines.
_______________________________________________
es-discuss mailing list
[email protected] [mailto:[email protected]]
https://mail.mozilla.org/listinfo/es-discuss
[https://mail.mozilla.org/listinfo/es-discuss]
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
