To illustrate that, I went to Github <https://github.com/search?l=JavaScript&q=await&ref=simplesearch&type=Repositories&utf8=%E2%9C%93>, I looked for repositories that match "await" and are JS (471 repositories). The first few hits where microframeworks with minimal code or language parser, but then comes:
Starhackit <https://github.com/FredericHeem/starhackit/tree/master/client/src> (3rd search result hit) some kind of full-stack application framework): - client/src/app/index.js <https://github.com/FredericHeem/starhackit/blob/master/client/src/app/index.js#L16>: async function run(), defers to await app.start - client/src/app/app.js <https://github.com/FredericHeem/starhackit/blob/master/client/src/app/app.js#L76>: async start(), defers to Promise.all of ii18nInit and preAuth - async i18nInit, defers to await intl - async preAuth, defers to await parts.auth.stores().me.fetch() And so on. I could go through most of these non minimal code repositories, and show you how every single one of them has async/await proliferated through their entire call chain top to bottom. I hope you can understand that my "theory" on actual use is therefore not just idle speculation, it's actual use reality, and you should consider that. On Sun, Feb 26, 2017 at 1: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
