Domenic Denicola wrote:
From: es-discuss<[email protected]> on behalf of Brendan
Eich<[email protected]>
> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
