Assuming Babel can get ahold of unmodified builtins, even if it's only during `@babel/runtime` initialization, it could still break that wrapper. `core-js` itself uses this trick extensively to dodge otherwise observable side effects in all of its wrappers. ūüėČ<br><br>(Babel *might* be invoking `wm.get(this)` and `wm.set(this)`, but it should really be binding those on initialization where possible.)<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 12, 2019 at 14:36 Ranando King <<a href="mailto:kingmph@gmail.com">kingmph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">@Isiah Remember, the class-fields proposal has absorbed the private-fields proposal, and it is those private fields that have no precise equivalent. WeakMap and closures can approximate what private fields do. However, private fields has semantics and capabilities that cannot be fully reproduced in current ES. For instance, I can wrap both WeakMap and Proxy in a way that Babel private-fields will be proxy safe. With native private fields, that's impossible.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 12, 2019 at 10:39 AM Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="auto">@Ranando Minor nit: class fields can be purely implemented in terms of `defineProperty` (for public) and weak maps (for private - what's used today for private data). Private methods could be implemented in terms of weak sets/maps and an object with methods outside the class's scope. Private static properties could just verify `this === Type`.</div></div><div dir="auto"><br></div><div dir="auto">So no, those don't quite reify classes, either. (If something can be fully transpiled or polyfilled, it doesn't create or reify any new primitives.)</div><div><br><div class="gmail_quote"></div></div></div><div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 12, 2019 at 09:51 Ranando King <<a href="mailto:kingmph@gmail.com" target="_blank">kingmph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I get what you're after. I touched on the same things when creating my private members proposal. The best of approaches for what you want is indeed relying on the lexical scope to act as a binding for all class members. There's just a couple of problems with doing things that way:<div><br></div><div>1. ES is a dynamic language. This makes lexical binding difficult because it's entirely possible to call a non-static class method where <font face="monospace, monospace"><b>this</b></font>¬†is undefined or null. Not allowing for that scenario will break existing code. Allowing for that scenario will cause variables to be unexpectedly either written to the global scope or throw.<br></div><div>2. Class isn't really a "thing" in ES, at least, it isn't until class-fields lands. The use of the <b style="font-family:monospace,monospace">class</b><font face="arial, helvetica, sans-serif">¬†keyword is currently completely optional. There's nothing in current ES that you can do with¬†</font><b style="font-family:monospace,monospace">class</b><font face="arial, helvetica, sans-serif">¬†that can't be done without it except use the </font><b><font face="monospace, monospace">super()</font></b><font face="arial, helvetica, sans-serif"> call in the constructor function. But even that can be substituted with </font><b><font face="monospace, monospace">Reflect.construct</font></b><font face="arial, helvetica, sans-serif">(). Class-fields will destroy this symmetry, making¬†</font><b style="font-family:monospace,monospace">class</b><font face="arial, helvetica, sans-serif">¬†it's own unique "thing". But until then, what do you do about all the "classes" that don't use the¬†</font><b style="font-family:monospace,monospace">class</b><font face="arial, helvetica, sans-serif">¬†keyword?</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Long and short, this means both the lexical scope approach and the alternate keyword approach will either break existing code or bring dubious-to-no benefit.</font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 12, 2019 at 3:06 AM john larson <<a href="mailto:johnlarsondev1@gmail.com" target="_blank">johnlarsondev1@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">So in terms of implementation, may be having instance method/property references on the objects and having static method/property references on the prototype is the solution?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 12, 2019 at 8:14 AM Isiah Meadows <<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've done a little engine work, and inline caches work by inline type maps based on the callee site. This *can* be used to reconstruct values + receivers, but only when the value is constant. It is not sufficient to ensure identity remains the same, and engines would still need a weak map to link methods to instances (as opposed to prototypes).<br><br>It's worth noting not even Java or Ruby offers this - their method references/objects (like our bound functions) are *not* memoized - they're linked to classes, not instances. Python is the exception here in auto-binding instance methods, not the norm.<br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 11, 2019 at 15:37 Bergi <<a href="mailto:a.d.bergi@web.de" target="_blank">a.d.bergi@web.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi John!<br>
> I think the js run-time already has that information at hand, so as<br>
> long as we don't implement this as pure syntactical sugar, there would<br>
> not be a need to keep an extra reference to anything, because it would<br>
> be¬†already there. The run-time will know which instance the invoked<br>
> method belongs to.<br>
<br>
Well no, you're wrong here: the runtime does not have this information<br>
at hand. In your example (simplified)<br>
```<br>
var reqManager = new RequestManager();<br>
function addEventListener(f) {<br>
¬† ¬† ¬†console.log(f);<br>
¬† ¬† ¬†f(event);<br>
}<br>
addEventListener(reqManager.responseHandler);<br>
```<br>
the `addEventListener` function will not know that the function `f` you<br>
passed was a method of the `reqManager` instance. It cannot distinguish<br>
that call from<br>
```<br>
addEventListener(RequestManager.prototype.responseHandler);<br>
```<br>
or<br>
```<br>
var g = otherReqManager.responseHandler;<br>
addEventListener(g);<br>
```<br>
<br>
It is exactly the same function that is passed in all three cases. There<br>
is no instance bound to `f`, and `f(event)` will not invoke it as a<br>
method (with a receiver/`this` value).<br>
<br>
Best regards,<br>
¬† Bergi<br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
</blockquote></div></div>
</div>
</blockquote></div>
</blockquote></div>