resolve()/reject() on Promise subclasses and @@species

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Oct 30 21:21:16 UTC 2015


+1

Allen

> On Oct 30, 2015, at 10:19 AM, Claude Pache <claude.pache at gmail.com <mailto:claude.pache at gmail.com>> wrote:
> 
> 
>> Le 29 oct. 2015 à 03:51, Boris Zbarsky <bzbarsky at MIT.EDU <mailto:bzbarsky at MIT.EDU>> a écrit :
>> 
>> I was just implementing subclassing of Promise in Gecko, when I realized that given a Promise subclass MyPromise these two calls:
>> 
>>  MyPromise.race([])
>>  MyPromise.all([])
>> 
>> will take MyPromise[@@species] into account when creating the return value, but these two calls:
>> 
>>  MyPromise.resolve()
>>  MyPromise.reject()
>> 
>> will not; they will invoke MyPromise itself, not MyPromise[@@species].
>> 
>> This is because http://www.ecma-international.org/ecma-262/6.0/#sec-promise.all <http://www.ecma-international.org/ecma-262/6.0/#sec-promise.all> and http://www.ecma-international.org/ecma-262/6.0/#sec-promise.race <http://www.ecma-international.org/ecma-262/6.0/#sec-promise.race> do the whole @@species thing but http://www.ecma-international.org/ecma-262/6.0/#sec-promise.reject <http://www.ecma-international.org/ecma-262/6.0/#sec-promise.reject> and http://www.ecma-international.org/ecma-262/6.0/#sec-promise.resolve <http://www.ecma-international.org/ecma-262/6.0/#sec-promise.resolve> do not.
>> 
>> Is this behavior intentional?  If so, I'd really like to understand the reason for it.
>> 
>> -Boris
> 
> Relevant discussion: https://esdiscuss.org/topic/performpromiseall <https://esdiscuss.org/topic/performpromiseall>
> 
> As I understand, the specified behaviour is an accident of history. Previously, `Promise.resolve()` and `Promise.reject()` used the species pattern in order to determine the constructor to be used, just as `Promise.all()` and `Promise.race()`. Then, at the last minute, it was decided that it wasn’t the best semantics for `Promise.resolve()`, and it was corrected. For `Promise.all()` and `Promise.race()`, the motivation wasn’t stronger than the lack of time.
> 
> Should it be corrected before @@species is widely implemented? I think so. The arguments I give are:
> 
> * Overall consistency in the language. Except for the two offending Promise static methods, all uses of `@@species` in the ES2015 spec (15 uses) are for the following pattern: Starting from one instance, one constructs a derived object for that instance. (The effective lookup of the @@species property is factored in the SpiecesConstructor and ArraySpeciesCreate abstract operations.)
> 
> * Also, in static methods like `Promise.all` and `Promise.race`, a constructor is explicitly provided by the user: simply use it. Compare with what is done for arrays:
> 
> 	Array.from(someArray) // use the Array constructor explicitly provided.
> 	Array.of(x, y, z) // ditto
> 
> 	someArray.slice(0) // compute the constructor to be used through some algorithm involving @@species.
> 	[].concat(x, y, z) // ditto
> 
> —Claude
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151030/0ce2127a/attachment-0001.html>


More information about the es-discuss mailing list