Promises (David Bruant)
lmeyerov at gmail.com
Sun Nov 11 17:46:00 PST 2012
> I wasn't aware of this and then read through about a dozen WebAPIs  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.
> Oh yes, of course, you can always build a promise library on top of the current APIs, blablabla... and waste battery with these libraries .
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..
More information about the es-discuss