Intent to replace Promise.jsm and promise.js with DOM Promises

David Rajchenbach-Teller dteller at mozilla.com
Tue Nov 19 17:05:49 UTC 2013


Generally, I believe that it's a good idea, if DOM Promises have the
equivalent of:

https://dutherenverseauborddelatable.wordpress.com/2013/10/14/recent-changes-to-promise-jsm-and-task-jsm/

Is this the case already?

Cheers,
 David

On 11/19/13 1:38 AM, Nikhil Marathe 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 at lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 


-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



More information about the firefox-dev mailing list