On Jun 10, 2015, at 8:22 AM, Domenic Denicola wrote:
> 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
I don't think we discussed the possibility of Promise subclasses with different
promise signatures at the May meeting; we mainly focused on the expectation
that SubPromise.resolve(x) should yield an instance of SubPromise. But I see
your logic, indirecting through species provides a way for subclasses to to
change their constructor signature and still work correctly with the other
inherited Promise static methods.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
