>
> I wasn't aware of this and then read through about a dozen WebAPIs [2]
> between yesterday and today and... discovered it's the case. In my opinion,
> one of the most absurd example is the DOMRequest thing which looks like:
> {
> readonly attribute DOMString readyState; // "processing" or "done"
> readonly attribute DOMError? error;
> attribute EventListener onsuccess;
> attribute EventListener onerror;
> attribute readonly any? result;
> };
>
> Read it carefully and you'll realize this is actually a promise... but it has
> this absurd thing that it has to have both an error and result field while
> only one is actually field at any given point.
> Also, these APIs and JavaScript as it they are won't support promise
> chainability and the excellent error forwarding that comes with it
> off-the-shelf. Also, the lack of a built-in Q.all really doesn't promote good
> code when it comes to event synchronization.
> Oh yes, of course, you can always build a promise library on top of the
> current APIs, blablabla... and waste battery with these libraries [3].
Reading the thread again, is this really the primary motivation for adding
promises? I don't see how the energy issue gets noticeably addressed, and so it
sounds like, indeed, "you can always build a promise library on top of the
current APIs."
There may be real expressive value to a serious promise proposal, however. It
can enable identifying asynchronous APIs and then 1) allowing frameworks to
introspect on them and 2) clarifying the succeed/fail protocol. Doing so with
standard promises seems awkward and insufficient, however, because their use
only becomes apparent via duck typing: you wrap every API call, intercept the
return, and check if it was a promise. Supporting introspection *before* the
call seems more desirable. (So, perhaps, the proposal would be for a special
async prototype added to any async API call).
Hopefully there is more discussion going on in backchannels here..
- Leo
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
