On 3/31/14 8:18 AM, Paolo Amadini wrote:
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.
Thanks. I'll see what I can do about getting these knocked out.
Tha
On 31/03/2014 13.42, David Rajchenbach-Teller wrote:
> I don't remember that we did any benchmark on this. I seem to remember
> that this was an assumption based on a discussion with bz a long time
> ago, but it might have been someone else.
Yes, memory was my source too.
On 31/03/2014 13.34, sma
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 con
On 3/31/14 1:34 PM, smaug wrote:
>> Promise.jsm and Promise are still interoperable from the functional
>> point of view, the difference is in the above non-functional
>> characteristics. Promise.jsm also has better performance due to the
>> fact that it avoids the JavaScript / C++ / JavaScript tur
On 03/29/2014 02:55 PM, Paolo Amadini wrote:
With bug 988122 landing soon, you'll now find a "Promise" object
available by default in the global scope of JavaScript modules.
However, this default implementation is still limited, and you're
strongly recommended to import Promise.jsm explicitly in
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 988
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-l
On 3/29/14 4:57 PM, Boris Zbarsky wrote:
For example, it has no Promise.race and no
Promise.prototype.catch.
And Promise.resolve() can throw in the case of Promise.jsm (which it can
never do per spec). I didn't dig into the details of the implementation
to look for any other incompatibilitie
On 3/29/14 7:33 PM, Gregory Szorc wrote:
> If Promise.jsm is obviously superior, why don't we expose that version
> to chrome-privileged global scopes by default? One less footgun.
If we did this, we would end up with two distinct Promise globals, with
two distinct semantics. This seems to me like
On 3/29/14 2:33 PM, Gregory Szorc wrote:
If Promise.jsm is obviously superior
It's not, as far as I can tell. Nor is it fully API-compatible with the
Promise spec. For example, it has no Promise.race and no
Promise.prototype.catch. So code that expects per-spec behavior may not
work with
On 3/29/14 8:55 AM, Paolo Amadini wrote:
- You get better performance on long Promise chains
Do we have hard data on this? I would be very interested in testcases
that show performance issues with the Promise objects we're shipping on
the web.
-Boris
_
On 3/29/14, 5:55 AM, Paolo Amadini wrote:
With bug 988122 landing soon, you'll now find a "Promise" object
available by default in the global scope of JavaScript modules.
However, this default implementation is still limited, and you're
strongly recommended to import Promise.jsm explicitly in ne
12 matches
Mail list logo
