Subclassing ES6 objects with ES5 syntax.

C. Scott Ananian ecmascript at
Sat Apr 25 20:22:20 UTC 2015

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

> On Fri, Apr 24, 2015 at 10:46 AM, Andrea Giammarchi <
> andrea.giammarchi at> 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 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 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

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list