On Fri, Aug 2, 2013 at 2:28 PM, Domenic Denicola < dome...@domenicdenicola.com> wrote:
> From: Mark S. Miller [erig...@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? > Damn. I'm glad you raised this. Yes, there are issues. I don't know what they are. Would someone more knowledgeable of this minefield like to answer? Thanks. > > 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. > I think tc39 quick consensus promises should not gratuitously differ from promises/A+, i.e., they should only differ when there's a well motivated reason, as with the addition of .flatMap and the shift of recursive flattening from the output side of .then to the input side. On #1, I like your parenthetical variant on DOM promise behavior (async rejection) better than either what promises/A+ does or what DOM currently mandates. On the others, tc39 consensus promises should follow promises/A+. > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
