I actually really like this idea. It reminds me of the C# syntax to try to
accomplish the same thing. Although under the bonnet C# uses "tasks",
which appear to be their form of promises, the surface code does look very
similar, take for example:
public async Task MyMethodAsync(){
Task<int> longRunningTask = LongRunningOperationAsync();
// independent work which doesn't need the result of
LongRunningOperationAsync can be done here
//and now we call await on the task
int result = await longRunningTask;
//use the result
Console.WriteLine(result);}
public async Task<int> LongRunningOperationAsync() // assume we return
an int from this long running operation {
await Task.Delay(1000); //1 seconds delay
return 1;}
Taken from this stackoverflow question
<http://stackoverflow.com/questions/14455293/how-and-when-to-use-async-and-await>.
I would be completely in support of shifting async/await from requiring
promises and instead allowing just the ability to use semi-normal "async
returns" (although, at the moment, I fail to see why one can't just use a
normal "return").
On Sun, Feb 26, 2017 at 12:43 PM, Florian Bösch <pya...@gmail.com> 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 <a...@weej.com> 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 <pya...@gmail.com> wrote:
>>
>>> On Sat, Feb 25, 2017 at 11:55 PM, Codefined <codefi...@debenclipper.com>
>>> 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
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
