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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
