On Fri, Apr 24, 2015 at 11:31 AM, C. Scott Ananian <ecmascr...@cscott.net> wrote:
> On Fri, Apr 24, 2015 at 10:46 AM, Andrea Giammarchi < > andrea.giammar...@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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
