On Fri, Jul 17, 2015 at 6:54 PM, Andrea Giammarchi < [email protected]> wrote:
> Meaning putting a Promise in a chain of promises is a point of no return > so I've never seen/heard/imagined a case where you have a promise and > suddenly you refactor that to be synchronous. > This is a great point, and I think makes a good argument against the refactoring use case. But there are other plenty of other interesting use cases (e.g. Bergi's IEAFE). Consistent sync/async resolution semantics would allow you to write generic sync/async handlers, which comes up all over the place. This approach neatly cleans up some of the inconsistencies around handling sync throws vs. rejections vs. *zalgo* throws (usually promise-returning functions which throw before returning a promise). A try/catch around some `await` will handle all three cases the same, almost -- there's one small catch (w/ apologies for the bad pun)... IIUC the behavior of `Promise.resolve` alone are insufficient to get identical semantics between sync and async calls -- you'd need to spin the event loop before rethrowing a sync exception, akin to the behavior of bluebird's `Promise.try`. A minor detail, but punting on this would force users into wrapping every call with something like `Promise.try`, which seems like a shame. ISTM these `try` semantics, rather than `Promise.resolve`, are more natural as the foundation for `await`. The specific "Promise gonna Promise" was actually mentioning another > thread about cancelability and the fact "Promises are Promises and should > just Promise" :-) > > Sorry for the confusion > > On Fri, Jul 17, 2015 at 10:41 PM, Mark S. Miller <[email protected]> > wrote: > >> Hi Andrea, what do you mean by "Promise must Promise"? I've never seen >> this phrase before. >> >> >> On Fri, Jul 17, 2015 at 11:35 AM, Andrea Giammarchi < >> [email protected]> wrote: >> >>> > Think about a large program where you refactor a single async >>> function to no longer be async >>> >>> did that ever happened in the history of logic? I am actually curious to >>> understand a single valid case where that would be a solution to any >>> problem. >>> >>> Apologies if I can't see your point but we've been talking about >>> "Promise must Promise" so much this answer was absolutely unexpected. >>> >>> Thanks for any sort of clarification >>> >>> On Fri, Jul 17, 2015 at 7:27 PM, Tom Van Cutsem <[email protected]> >>> wrote: >>> >>>> 2015-07-17 19:41 GMT+02:00 Andrea Giammarchi < >>>> [email protected]>: >>>> >>>>> 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. >>>> >>>> regards, >>>> Tom >>>> >>>> >>>> >>>>> >>>>> Just my quick thoughts >>>>> >>>>> Best Regards >>>>> >>>>> On Fri, Jul 17, 2015 at 6:33 PM, Kevin Smith <[email protected]> >>>>> wrote: >>>>> >>>>>> 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 >>>>>> [email protected] >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> es-discuss mailing list >>>>> [email protected] >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> >> -- >> Cheers, >> --MarkM >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
