Promises Consensus with /A+ terminology
domenic at domenicdenicola.com
Fri Aug 2 14:28:45 PDT 2013
From: Mark S. Miller [erights at google.com]
> A good start would be to convert https://github.com/promises-aplus/promises-tests to test262 form, extending test262 in the process in order to accommodate async testing. Any volunteers?
If someone does the latter (preferably with a simple Mocha-like `done()` facility), I will happily do the former. I imagine there might be licensing issues with non-Ecma members; would that still be the case for code licensed under the WTFPL?
The only divergence between DOM promises and Promises/A+ so far are:
1. The handling of non-`undefined`, non-function arguments, which Promises/A+ mandates must be ignored while DOM Promises mandate must throw a synchronous `TypeError`. (This is a spec bug; it should result in an asynchronous `TypeError` rejection.)
2. DOM Promises requires `onFulfilled` and `onRejected` to be called as if they were methods of the promise itself, whereas Promises/A+ requires they be called as functions.
3. DOM Promises mandates an infinite loop for the code `const q = fulfilledPromise.then(() => fulfilledPromise)`, whereas Promises/A+ mandates that `q` be rejected with a `TypeError`.
4. DOM Promises mandates an infinite loop for the code `const q1 = fulfilledPromise.then(() => q2); const q2 = fulfilledPromise.then(() => q1)`, whereas Promises/A+ allows (but does not require) that implementations reject `q1` and `q2` with a `TypeError`.
Of these, 1 I am ambivalent on, 2 I think was a very strange mistake, and 3 and 4 feel like oversights. But none of them are a big deal.
More information about the es-discuss