domenic at domenicdenicola.com (2013-08-05T20:11:08.982Z)
On Fri, Aug 2, 2013 at 2:42 PM, Mark Miller <erights at gmail.com> wrote: > 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. I retract this. Although I would like it better, it is not worth diverging from promises/A+ on this one. Let's stick to promises/A+ except where it really matters (.flatMap and recursive unwrapping on input side)
On Fri, Aug 2, 2013 at 2:42 PM, Mark Miller <erights at gmail.com> wrote: > On Fri, Aug 2, 2013 at 2:28 PM, Domenic Denicola < > domenic at domenicdenicola.com> wrote: > >> 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? >> > > 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. > I retract this. Although I would like it better, it is not worth diverging from promises/A+ on this one. Let's stick to promises/A+ except where it really matters (.flatMap and recursive unwrapping on input side) > > On the others, tc39 consensus promises should follow promises/A+. > > > > >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > -- > Text by me above is hereby placed in the public domain > > Cheers, > --MarkM > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130802/f995274e/attachment-0001.html>