await on synchronous functions
gilt at wix.com
Fri Jul 17 18:50:13 UTC 2015
I would tend to agree with Tom (i.e. Promisify non-promises), even though
we should notice that awaiting a synchronous function adds a non-trivial
overhead, because although the promise is immediately resolved, the await
will "return" only after being processed in the event loop (if I remember
the Promise spec correctly).
So if option #1 has the advantage of "alerting" us to this performance
effect, why do I still prefer option #2? Because of consistency - this is
similar to the callback the ".then" of a promise accepts: if the callback
returns a promise, it is chained, and if it is a regular value, then it is
promisified and chained.
The same two options exist there, and the spec decided on #2. And
rightfully so. I like the fact that the code "just works" and in languages
like JS, I would prefer it "just working" than being "statically correct".
Dynamic languages lots of time tend to prefer the "just works, albeit
slowly" approach to the "theoretically and statically correct" approach.
On Fri, Jul 17, 2015 at 9:27 PM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
> 2015-07-17 19:41 GMT+02:00 Andrea Giammarchi <andrea.giammarchi at gmail.com>
>> If I might, if there's one thing that has never particularly shone in JS,
>> that is consistency.
>> I see only two possibilities here: 1) it throws with non Promises 2) it
>> "Promisify" anything that's not a Promise as if it was a
>> `Promise.resolve(1)` ... but since there's too much magic in the second
>> point, I'd rather stick with the first one.
> I would be highly in favor of (2). Think about a large program where you
> refactor a single async function to no longer be async. Then I see no
> reason why I should be forced to refactor all of its callers to remove the
> await keyword. Going from sync to async requires refactoring because you're
> introducing new potential interleaving hazards, but any code that is
> already prepared to work with async functions (or promises in general)
> should work equally fine on immediately resolved promises.
>> Just my quick thoughts
>> Best Regards
>> On Fri, Jul 17, 2015 at 6:33 PM, Kevin Smith <zenparsing at gmail.com>
>>> I know the spec for this isn't finalized, but what is the current
>>>> direction for the behaviour when await is used on a function that is not
>>>> marked async and doesn't return a Promise? Should it run immediately or
>>>> wait for the next turn of the event loop?
>>> More generally, the question is: what should await do for non-promises?
>>> await 1;
>>> Should it force a job to be queued?
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
Software Architect @ Wix
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss