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
