PerformPromiseAll

Mark S. Miller erights at google.com
Tue Jun 9 14:38:44 UTC 2015


It would help to have a concrete motivating example where the Promise
subclass were usefully distinct from the Promise subclass' species.


On Tue, Jun 9, 2015 at 7:30 AM, C. Scott Ananian <ecmascript at cscott.net>
wrote:

> `Promise.resolve` doesn't use the species pattern any more:
> https://esdiscuss.org/topic/fixing-promise-resolve
> The rationale was that `resolve` is more like a constructor than a mutator.
>
> I don't have a strong opinion about `Promise.all`, but I think perhaps it
> would be better if none of the static methods of `Promise` (Promise.all,
> Promise.race, Promise.reject) used the species pattern, which is more
> appropriate for instance methods (like `Promise.prototype.then`, where it
> is a natural fit).
>
> However, consider another way of looking at it.  Let's make the
> fundamental implementation `Promise.prototype.all` (defined by some utility
> libraries, including bluebird and prfun, and would be a good candidate for
> ES7) which operates on a promise resolving to an array.  It seems natural
> for that to use a species pattern, since it's an instance transformation
> method, like `then` and `catch`.  The natural implementation of
> `Promise.all` would then be:
> ```
> Promise.all = function(a) { return this.resolve(a).all(); };
> ```
> This doesn't use the species pattern for the initial `resolve`, but then
> does use it to implement the instance method `all`. So the result of
> `Promise.all` effectively uses the species pattern.
>
> So: on one hand, static methods don't use @species.  On the other,
> `Promise.prototype.all` would naturally use the species pattern, and that
> suggests a natural implementation of `Promise.all` would as well.  On the
> gripping hand, given a non-species-using `Promise.all`, it is easy to
> define `Promise.prototype.all` (just do the initial `resolve` using the
> species), but the converse isn't true.  So perhaps a non-species-using
> `Promise.all` would be a more useful building block.
>
> I'd appreciate further opinions here.  My bias is against trying to make
> late changes to the ES6 spec, so perhaps I'm rationalizing away the
> potential problems with `Promise.all` and `Promise.race`.
>   --scott
>
>
> On Tue, Jun 9, 2015 at 6:46 AM, Axel Rauschmayer <axel at rauschma.de> wrote:
>
>>
>> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-performpromiseall
>>
>> I’m wondering: Is it OK that PerformPromiseAll invokes `resolve()` via
>> `C.resolve()` (versus `this.resolve()`) with `C` determined via the species
>> pattern?
>>
>> Rationale: `resolve()` uses the species pattern, too (which is why
>> `this.resolve()` works well). Therefore, the species pattern is used twice,
>> which may lead to unexpected effects: You define the species of `this` to
>> be X, but the species of X is Y. Then `Promise.all()` creates an array with
>> instances of Y, not X.
>>
>> --
>> Dr. Axel Rauschmayer
>> axel at rauschma.de
>> rauschma.de
>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150609/92658540/attachment.html>


More information about the es-discuss mailing list