Subclassing ES6 objects with ES5 syntax.

[C. Scott Ananian]

On Fri, Apr 24, 2015 at 11:31 AM, C. Scott Ananian <ecmascript at cscott.net>
wrote:

> On Fri, Apr 24, 2015 at 10:46 AM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> So you should do the same with Promise methods but then you'll see
>> overall a quite consistent performance drop when using all these subclasses.
>>
>
> Well, not exactly.  The Promise methods are all written to use the correct
> constructor (perhaps a (welcome) artifact of the fact that they were
> spec'ed before this change in instantiation mechanism?):
>

Hm.  Well, almost: Promise.resolve uses the hidden [[PromiseConstructor]]
property, which is initialized from new.target at construction time.  So we
need to use a native `Reflect.construct` to ensure that is set correctly
(or just work around it by overriding `Promise.resolve` while we wait for
engines to implement ES6 class semantics).

This begs the question: what, exactly, is `Promise.resolve` accomplishing
by using a different mechanism for determining the "class of the
constructor" than every other promise-related method.  In
https://bugs.ecmascript.org/show_bug.cgi?id=2513 the answer given was "for
allowing tamper-proof casting via private slots."  But in the code given
previously, I've used `Object.setPrototypeOf` to effectively change the
type of the object -- but [[PromiseConstructor]] doesn't follow along.
Seems a little ineffectual, although perhaps if you care about
"tamper-proof casting" you've already disabled access to
`Object.setPrototypeOf`?

I think I'd rather see `Promise.resolve` changed to use `this.constructor`
instead of `this.[[PromiseConstructor]]`, like every other Promise-related
method.  Can someone who feels strongly otherwise give me the use case for
`[[PromiseConstructor]]` existing?
 --scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150425/7015dd33/attachment.html>