On 29/03/2014 21.57, Boris Zbarsky wrote: > For example, it has no Promise.race and no Promise.prototype.catch.
It does, as soon as bug 941920 lands. We were holding it off due to compatibility concerns, but the general availability of the DOM Promise object changes the landscape and we're crash-landing it (I'd have appreciated some coordination on this, but bug 988122 was off radar). To add more complexity to the mix, there is still the presence of legacy Add-on SDK Promises that don't have a "catch" method and resolve synchronously. Most notably, until bug 887923 lands, Task.jsm is still using those. Updating legacy promises tends to block on the synchronous behavior that most tests expect. This is a just a portion of the complex situation we have with Promises. I was planning on doing a dev.platform post for a status update next week, but this landing changed things and I chose to communicate one specific aspect first, that is the purpose of Promise.jsm and the need to do some work to make DOM Promises on par. For details on in-progress work, you can refer to the unsorted dependency tree of the Promises tracking bug: https://bugzilla.mozilla.org/showdependencytree.cgi?id=856878&hide_resolved=1 > So code that expects per-spec behavior may not > work with the Promise exported by Promise.jsm. In most cases, code will work exactly in the same way. If it doesn't, that is a Promise.jsm bug to be fixed. I'm not talking about code designed to rely on edge cases - passing the full DOM Promise test suite is a non-goal for Promise.jsm. The goal is to be able to switch to DOM Promises as a drop-in replacement for Promise.jsm, when ready. The "Cannot resolve a promise with an async function." error is an example of a non-compliant behavior we've introduced to help programmers avoid footguns. I'd add this to the list of reasons to recommend "Promise.jsm", though obviously we will (rightfully) lose this error when switching to the compliant implementation. Making Promise.jsm developer-friendly was a significant investment of time and effort under Mozilla's Performance and Async projects, and we want to be sure we can capitalize on that experience while moving forward to ES6/DOM Promises. Cheers, Paolo _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
