- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Fri, 30 Aug 2013 13:53:50 +0000
- To: "es-discuss@mozilla.org" <es-discuss@mozilla.org>
- CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, "www-dom@w3c.org" <www-dom@w3c.org>
Anne, Mark, and I are working through the details on revising DOM promises to match the updated AP2 consensus we've developed over these many es-discuss promise threads. There is one change we were hoping to make from the DOM promises spec that has not been discussed before, so we wanted to run it by the list to make sure there were no objections. All existing promise implementations that use the constructor pattern, e.g. Q, WinJS, YUI, RSVP, when, then/promise, and others, give the constructor arguments as `new Promise((resolve, reject) => ...)`. This was codified in [a Promises/A+ strawman][1] which has met with wide agreement among the implementer community. The current DOM promises draft gives the constructor arguments as `new Promise(resolver => ...)` where `resolver` is an instance of the `PromiseResolver` class and has `resolve`, `reject`, and `fulfill` methods. With the AP2 changes, `fulfill` no longer is necessary (you will use `Promise.of` for that use case), so this would be reduced to `resolve` and `reject` methods. Note that `PromiseResolver` is a full-fledged constructor with its own prototype, and the `resolve` and `reject` methods are actually methods, i.e. can't be extracted without binding, so in particular using destructuring syntax like `new Promise(({ resolve, reject }) => ...)` will not work. Since there's no real advantage to the `PromiseResolver` approach, and there are a number of disadvantages, we were hoping to switch to the prevalent `(resolve, reject)` signature in the revised DOM promises spec. Let us know what you think! [1]: https://github.com/promises-aplus/resolvers-spec/issues/18
Received on Friday, 30 August 2013 13:54:58 UTC