Ron it's not about being ambiguous, it's actually the opposite: know when returning directly a value would actually break "outside expectations"
So my idea is to indeed offer either a sync or an async result and not both (in terms of same execution context/scope/logic) On Thu, Dec 3, 2015 at 5:48 PM, Ron Buckton <[email protected]> wrote: > I agree with Bradley, and kindly refer you to this oft referenced blog > post regarding synchronous and asynchronous APIs: > http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/ > > > > Ron > > > > > > > *From: *Bradley Meck > *Sent: *Thursday, December 3, 2015 8:57 AM > *To: *Andrea Giammarchi > *Cc: *[email protected] > *Subject: *Re: Reflection to know if executed within a generator/async ? > > > > > I am against any semantics that expose how a function is used. I struggle > and many others do when this occurs in CSS (display varies depending on > container). I would also be hesitant to encourage things acting both > synchronously and asynchronously depending on how they are used. Changing > temporal behavior depending on usage is asking for race conditions. > > On Thu, Dec 3, 2015 at 10:37 AM, Andrea Giammarchi < > [email protected]> wrote: > >> Uhm... you never closed that "will this value be .... thing and I'm >> expecting a "dary" answer like in few emails but my whole point is >> consuming an API in different scenarios: held or synchronous. >> >> You can always create an API that always returns a Promise, that's >> nothing new for the language, but can you decide if it's he case to >> absolutely return a promise 'cause any other value would cause trouble >> within that generator or async function? >> >> On Thu, Dec 3, 2015 at 4:15 PM, John Lenz <[email protected]> wrote: >> >>> I don't think being executed in a generator or async function is a good >>> signal that a promise should be returned (something needs to "await" the >>> promise). The async function is really a chain of synchronous code split >>> at various points, during the synchronous parts the code would still need >>> to be synchronous and returning a promise would be wrong. The real data >>> you need is "will this value be consumed by an 'await' expression or be >>> used to resolve a Promise and, in the general case, that is not something >>> that can't be answered at the time your example function is executing. >>> >>> On Thu, Dec 3, 2015 at 4:15 AM, Andrea Giammarchi < >>> [email protected]> wrote: >>> >>>> Hi there, >>>> just writing down some thoughts about being able to understand if a >>>> method/function has been executed within a generator/async and is being >>>> yielded/awaited. >>>> >>>> Rationale: API that would like to behave synchronously in some case, >>>> returning Promises in other cases. >>>> >>>> Example: >>>> >>>> ```js >>>> function fileGetContent(fileName) { >>>> // random example >>>> if (held) { >>>> return fetch(fileName).then((r)=>r.text()); >>>> } else { >>>> var xhr = new XMLHttpRequest; >>>> xhr.open('GET', fileName, false); >>>> xhr.send(null); >>>> return xhr.responseText; >>>> } >>>> } >>>> ``` >>>> >>>> Above example will virtually return always the same type and it could >>>> work inside a generator or an async function as long as it's being held. >>>> >>>> Does any of this make sense? Is it worth exploring this pattern? >>>> >>>> Thanks for any sort of thought. >>>> >>>> Best Regards >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.mozilla.org%2flistinfo%2fes-discuss&data=01%7c01%7cron.buckton%40microsoft.com%7c884c0e07599b45dd22f108d2fc02d478%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pYbuVGySrXg%2fl7oapX7JO3YVMIsZpEmbdykdXYgGKIs%3d> >>>> >>>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.mozilla.org%2flistinfo%2fes-discuss&data=01%7c01%7cron.buckton%40microsoft.com%7c884c0e07599b45dd22f108d2fc02d478%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pYbuVGySrXg%2fl7oapX7JO3YVMIsZpEmbdykdXYgGKIs%3d> >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
