alex at dojotoolkit.org
Mon Nov 12 02:41:50 PST 2012
I *really* don't want to wade deep into these waters, but I'll respond a bit here to correct errors:
On Nov 11, 2012, at 9:02 PM, Leo Meyerovich <lmeyerov at gmail.com> wrote:
> I've been lurking on this thread and am somewhat confused. Is the motivation for promises a needed expressive primitive, updating the standard library to have asynchronous calls and structure them via promises, sugar, or something else? I assume it's not to proscribe one particular style of coordination over another, which would have little empirical validation.
Putting things into a language or standard library in no way "proscribes" alternatives; it does however anoint one variant as "idiomatic". To the extent a built-in does that, it should be following practice. Now, perhaps you haven't been watching the mis-designs in DOM or the ubiquitous promise/future/deferred-like libraries that are now part of every major JS toolkit on the client side (still our major user). Or perhaps you think that doesn't hold a lot of water as the language can go its own way (a view I'm *obviously* sympathetic to). But either way, I think Promises have value in that they:
* were the basis for the underlying API we used to describe what happened when functions were de-sugared in the "await" proposal. They can do something similar for generators and, as someone who dislikes magic in general, I think we should do that work.
* the weight of library authors sending down their own versions of this stuff is MASSIVE and *should* inform what we do. Any other bias needs massive justification. So yes, we have tons of validation on this. Just look around.
> -- If it's for asynchronous standard API, why shouldn't coordination be a user-level framework decision? E.g., have one callback for each async API (or two, succeed and fail), and leave the rest up to the coordination framework of the day? Simple API structure, like one of these patterns, will help framework writers make generic wrappers, but introducing more seems excessive. The main use case for APIs would be (AFAICT) to allow frameworks to introspect on whether an API call is async. Promises would enable inspecting the return value, but this seems awkward and maybe even late.
> -- If the motivation is for language-level issues, I'm curious as to how this relates to topics like compiler optimization, multiprocessing, cross-frame communication, etc. Furthermore, are there any semantic concerns coming up (e.g., E style vats), or is the intent here purely sugar? (I assume blocking on a Liskov-style future will not be allowed).
> -- For sugar, a lightweight lambda and, if still desired, macros, seem to eliminate much of the need of a primitive.
> Hopefully my confusion as to the motivation and design space here is clear :)
> - Leo
> es-discuss mailing list
> es-discuss at mozilla.org
slightlyoff at google.com
slightlyoff at chromium.org
alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
More information about the es-discuss