Subclassing ES6 objects with ES5 syntax.
C. Scott Ananian
ecmascript at cscott.net
Sat Apr 25 20:22:20 UTC 2015
On Fri, Apr 24, 2015 at 11:31 AM, C. Scott Ananian <ecmascript at cscott.net>
> 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss