There are add-ons using the existing promises implementations. Is there any reason not to make those wrappers around the DOM promises to avoid potential bustage?
At least the add-on SDK promises library provides functionality beyond that that appears to be in the DOM promises (custom prototypes for example). How are you planning to handle that? On Mon, Nov 18, 2013 at 4:38 PM, Nikhil Marathe <nsm.nik...@gmail.com>wrote: > (Cross posted to firefox-dev, please reply on dev.platform) > > DOM Promise has been in the tree for a while, and is enabled for > ChromeWorkers and certified apps. With a couple of patches, it will achieve > conformance with the AP2 spec [1], which is what TC39 has accepted as the > bare minimum for Promises in ECMA6. It will also be available on Workers as > long as the pref is enabled. We currently have two JS promise > implementations in our codebase: > toolkit/modules/Promise.jsm > addon-sdk <http://mxr.mozilla.org/mozilla-central/source/addon-sdk/ > >/source<http://mxr.mozilla.org/mozilla-central/source/addon-sdk/source/> > /lib <http://mxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/ > >/ > sdk< > http://mxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/> > /core< > http://mxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/core/ > > > /promise.js< > http://mxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/core/promise.js > > > > which offer a different API and reimplement some code, one for chrome, one > for content. > > My intention is: > 1) Enable Promises for all chrome code. > 2) Set dom.promise.enabled to true for tests > 3) Migrate all users of the two promise implementations to the new style > (including tests). > 4) Get rid of these two JS implementations. > The work is being tracked in Bug 939636 [2]. > > It would be a great help if developers who work on code using Promises > could download the patch that enables Promises in chrome and submit patches > to that bug updating code/tests. > The new spec has a different style of creating promises, which may not > interface well with callback oriented code. Feel free to ping me (nsm on > IRC) if you need help. > > If there is a reason this shouldn't be done, please let me know. > > At some point in the future Spidermonkey will implement Promises natively, > at which point (theoretically) all the code can simply transition to that > with no changes. > > Nikhil > > [1] https://github.com/domenic/promises-unwrapping > [2] https://bugzil.la/939636 > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
