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

john larson johnlarsondev1 at gmail.com
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 gmail.com> 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 gmail.com> 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 icloud.com> 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 (https://github.com/tc39/proposal-bind-operator)
>>> 2: Babel Plugin (
>>> https://babeljs.io/docs/en/next/babel-plugin-proposal-function-bind)
>>>
>>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190311/4a9d54fe/attachment-0001.html>


More information about the es-discuss mailing list