<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 style=""><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 style=""><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">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>