Re: Re: Proposal For A New Alternative Keyword To “this” For Classes

john larson johnlarsondev1 at
Mon Mar 11 15:55:00 UTC 2019

Well, actually this is the same discussion we had with *@Jordan Harband. *I
think the js run-time already has that information at hand, so as long as
we don't implement this as pure syntactical sugar, there would not be a
need to keep an extra reference to anything, because it would be already
there. The run-time will know which instance the invoked method belongs to.
But as I said, it would be insightful to get a js engine expert opinion on
this. Having said that, I believe it is just an implementation detail and
can be handled one way or the other. I guess the “class property arrow
methods in React" example you just provided also supports this notion.

On Mon, Mar 11, 2019 at 6:23 PM Ben Wiley <therealbenwiley at> wrote:

> The main issue here is that you're sort of asking for something too late.
> If you reference the "notThis" keyword inside a callback method that has
> been separated from "its own" class instance, you're now saying "could you
> please do this all in the context of your instance", but your method
> doesn't know what its instance is because it never saved a reference.
> Alternatively the compiler would notice that the "notThis" keyword is
> invoked inside a method, and automatically make a bound property on
> construction. The problem is that you're eagerly making a copy of every
> method using "notThis" for every instance that exists - eating up a whole
> bunch of extra memory for large collections - without knowing necessarily
> that those bound copies will be used. Granted, we're triggering the same
> problem when folks are using "class property arrow methods" for all their
> methods in React classes.
> Ben
> Le lun. 11 mars 2019 11 h 04, john larson <johnlarsondev1 at> a
> écrit :
>> *@Rob:* Thanks for pointing out "proposal-bind-operator". I examined the
>> proposal and as far as I understand, it is just another way to create a
>> bound enclosing function. What I am proposing is just the opposite, no
>> binding should take place in the enclosing function. A method call or usage
>> of a property should already have its lexical scope pointing to the class
>> instance and should not need any binding of its enclosing environment to
>> function correctly.
>> On Mon, Mar 11, 2019 at 4:57 PM Rob Ede <robjtede at> wrote:
>>> I would imagine that this can be achieved with bind operator proposal,
>>> which already has Babel support, despite no examples showing usage inside a
>>> class.
>>> Something like:
>>> `oReq.addEventListener("load", ::this.responseHandler);`
>>> seems to be the syntax that will de-sugar to
>>> `oReq.addEventListener("load", this.responseHandler.bind(this));`
>>> to get you the desired this binding.
>>> I’m surprised this idea hasn't been mentioned yet although things have
>>> been moving slowly on that proposal and it seems to need some community
>>> support to move along.
>>> Regards,
>>> Rob
>>> References:
>>> 1: Bind Syntax Proposal (
>>> 2: Babel Plugin (
>>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list