On 3/30/14 6:00 AM, Paolo Amadini wrote:
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).
Hmm. I don't think it was clear to anyone working on the DOM/ES6 promises that were were trying to treat them as "do not use" kind of things.
We should work on fixing the issues you pointed out, and I would _still_ like hard data on the performance problems you claim with long Promise chains.... Presumably we have measurements we've done here?
In most cases, code will work exactly in the same way.
Sure. But the reason we in my opinion can't just default all scopes to Promise.jsm is that it in fact does _not_ work in exactly the same way in all cases, and people writing green-field code will likely assume a spec-compliant Promise implementation, not just something kinda similar.
The goal is to be able to switch to DOM Promises as a drop-in replacement for Promise.jsm, when ready.
Can we define "ready"? Is the list of issues you listed in your post at the start of this thread the full list of blockers for dropping Promise.jsm?
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"
It's a reason we can't just default to Promise.jsm, though... For example, would it be sufficiently developer-friendly to log something in this case but proceed instead of throwing? If so, is that something that would make sense to do for ES6 promises as well? Logging things to console is obviously not defined by any specs, so we have wide latitude here.
-Boris _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
