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

Ben Wiley therealbenwiley at gmail.com
Mon Mar 11 16:20:03 UTC 2019


Whatever the implementation, I'd be surprised to learn that the browser
*does* have the information automatically and wouldn't need to store
additional memory similar to .bind().

But I'm also not a browser engine expert, so there's that.

Le lun. 11 mars 2019 11 h 55, john larson <johnlarsondev1 at gmail.com> a
écrit :

> 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/26117d0a/attachment.html>


More information about the es-discuss mailing list