On 30/03/2014 22.10, Boris Zbarsky wrote: > 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.
Obviously, that is not what anyone is proposing here :-) DOM Promises are already enabled by default in content, thanks to the great work that has been done on both implementation and specification. We should make sure that chrome code can fully benefit from that work as soon as possible. (We're already seeing a partial benefit, since Promise.jsm is still based on the DOM Promises specification work.) >> 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. I also want to clarify that I don't think Promise.jsm should be imported by default in chrome code at this point, despite its advantages. > 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? I've edited bug 939636 to depend on three key issues out of the list I posted before. I think that once those are addressed, there will be no reason to stick to Promise.jsm any longer. > 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. That looks like a good idea to me. Cheers, Paolo _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
