Brendan Eich (2014-01-28T20:48:58.000Z)
Domenic Denicola wrote:
> From: es-discuss<es-discuss-bounces at mozilla.org>  on behalf of Brendan Eich<brendan at mozilla.com>
>
>> >  Quildreen Motta wrote:
>>> >>  If that's correct, I don't see any use cases for Promise.resolve right now, unless a library where to provide a corresponding unspecified `flatMap` implementation.
>> >
>> >  IIRC (and I may not; endless promises threads make me sleepy) this is the reason to have Promise.resolve: to enable some to blaze the flatMap trail ahead of ES6.
>
> Kind of. Since `Promise.resolve(x)` is just `new Promise(resolve =>  resolve(x))`, the only reasons for including that shorthand method are symmetry and the idea that this operation might be common enough to necessitate a shorthand. See my earlier reply.
>
> On the other hand, that*is*  part of the reason we moved all the unwrapping to the `then` side---as Mark puts it, using the "accept" operation instead of "resolve," albeit while still using the "resolve" name. (Which is pretty confusing when you try to explain it, but I swear, it makes sense...)

I buy it.

Paolo may not. Mozilla XUL JS does seem full of .resolve calls, some of 
which might want to be .cast calls instead.

/be
forbes at lindesay.co.uk (2014-01-29T00:41:49.209Z)
I buy it.

Paolo may not. Mozilla XUL JS does seem full of .resolve calls, some of 
which might want to be .cast calls instead.