<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 24, 2015 at 11:31 AM, C. Scott Ananian <span dir="ltr"><<a href="mailto:ecmascript@cscott.net" target="_blank">ecmascript@cscott.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Apr 24, 2015 at 10:46 AM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.</div></blockquote><div><br></div></span><div>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?):</div></div></div></div></blockquote><div><br></div><div>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).</div><div><br></div><div>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 <a href="https://bugs.ecmascript.org/show_bug.cgi?id=2513">https://bugs.ecmascript.org/show_bug.cgi?id=2513</a> 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`?</div><div><br></div><div>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?</div><div> --scott</div><div><br></div></div></div></div>