On Monday, November 18, 2013 5:36:48 PM UTC-8, Brandon Benvie wrote: > On 11/18/2013 4:54 PM, Dave Townsend wrote: > > > 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? > > > > It is pretty trivial to wrap the DOM Promise implementation so that it's > > compatible with code using Promise.jsm (Deferreds) [1]. More difficult > > is porting code using the addon-sdk (which can synchronously resolve > > promises) to the async implementations (either DOM Promises or > > Promise.jsm). Work is ongoing to port the devtools (which make extensive > > use of addon-sdk promises) to Promise.jsm [2]. > > > > [1] https://gist.github.com/Benvie/58f32410073b8a10d03f > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=881050
Is there are reason devtools cannot switch to DOM Promises directly rather than go through making Promise.jsm a wrapper around DOM Promise? The current promise implementations which allow resolving later are leading to very un-idiomatic promise code in the tree, and the encapsulation of (resolve, reject) being 'private' to the constructor callback should force a better style and easier to read code. If addon-sdk allows synchronously resolving promises, I'd like to help in a migration path that ensures these are not abused, and eventually gotten rid off. In the current spec, and as far as I know, Promises have always resolved asynchronously. Synchronous resolution can lead to various problems including running out of stack space and unintentional blocking code. Nikhil _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
