Allen, that change seems wrong. I thought we were only changing the IsPromise
steps. The actual construction should still go through species. If nothing
else, it should do so for consistency with reject.
The motivation of @@species, as I understood it, was to allow alternate
subclass constructor signatures (originally for Array and TypedArray, but
Promise can benefit as well). It’s understandable to not involve @@species when
doing weak type-tests. But any time you construct a promise instance, you
should go through @@species, instead of the constructor directly.
Some example usages:
- Creating a LabeledPromise subclass (for better debugging, like RSVP's
promises + Ember promise inspector) whose constructor signature is `new
LabeledPromise(label, executor)`
- Creating a SaneArray subclass whose constructor signature is `new
SaneArray(...elements)` without the special-case for a single argument.
- A more complicated usage in a proposed Element/HTMLElement/MyCustomElement
hierarchy [1], to allow custom elements to have custom constructor signatures
but still work well with various element-creating parts of the platform.
The LabeledPromise case will, as currently specified, work great.
LabeledPromise has a custom `LabeledPromise[Symbol.species](executor)` which
basically does `return new this("<derived promise>", executor)`. Then it
doesn't have to override `.resolve`, `.reject`, `.all`, or `.then`. However,
with your change, `.resolve` will no longer work correctly, even though
`.reject` will.
However, the SaneArray case actually will only work for the instance methods,
which use ArraySpeciesCreate. In contrast, Array.of and Array.from use
Construct(C, <<len>>). That seems like a bug in the spec?
[1]:
https://github.com/domenic/element-constructors/blob/cdfe5a1d865e25d265074418df7918fda959e403/element-constructors.js#L101-L107
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
