> > It's important, as someone who hands off an arrow function to another part > of the system, to ensure that `this` means what it meant while I was > originally writing the code. This guarantee is vital for predictability of > behavior. Consider > let mapped = array.map((el) => el * this.x) > If I cannot guarantee a lexical `this`, I am back to programming with `let > that = this`, which is part of what arrow functions are trying to avoid. > The only alternative is reading the source code and/or spec for every > system that I hand off an arrow function to, since I need to know if they > will clobber the lexical `this` I was trying to program against. > Note that this isn't a security issue---I'm not worried about "malicious > code" messing me up. I'm simply trying to juggle the minimum number of > factors on my precious brainstack, and when I'm trying to get a mapped > array, I really don't want to think about whether `map` is going to mess > with my `this`.
I understand your argument, but I think it is more important to be able to switch in full to the new function operator(s), not sometimes one, other times the other. `function` is old, it supports deprecated/old things like `arguments` and `caller`. This kind of says `bind/call/apply` are old too and in some fashion discourages their use. Even if that is not the intent, it happens by association, Using `=>` but being forced to using `function` anytime I want dynamic this just doesn't work. If the goal is to discourage use of bind/call/apply on functions (this doesn't include methods), then I would say this spec makes sense, otherwise, we need a non hard |this| binding as part of fat arrows, or we need skinny arrow. On Sat, Apr 21, 2012 at 1:17 PM, Domenic Denicola < [email protected]> wrote: > > -----Original Message----- > > From: [email protected] [mailto:es-discuss- > > [email protected]] On Behalf Of Angus Croll > > Sent: Saturday, April 21, 2012 16:03 > > To: Allen Wirfs-Brock > > Cc: es-discuss > > Subject: Re: A few arrow function specification issues > > > > >>4) Should it be a dynamic error to try to use apply/call to set the > > this binding of an arrow function. > > > > >>Cons > > >>To much existing code speculatively binding the this value when > > invoking a function. > > > > >>I propose that call/apply simply ignore the this value when invoked on > > an arrow function. > > > > What is the pro of ignoring explicit |this| binding instructions in > > call/apply on arrow functions? > > What is the con of continuing to allow legacy code to speculatively bind > > the |this| value when invoking any function? > > Why is it so important that fat arrows do a hard |this| binding? > > It's important, as someone who hands off an arrow function to another part > of the system, to ensure that `this` means what it meant while I was > originally writing the code. This guarantee is vital for predictability of > behavior. Consider > > let mapped = array.map((el) => el * this.x) > > If I cannot guarantee a lexical `this`, I am back to programming with `let > that = this`, which is part of what arrow functions are trying to avoid. > The only alternative is reading the source code and/or spec for every > system that I hand off an arrow function to, since I need to know if they > will clobber the lexical `this` I was trying to program against. > > Note that this isn't a security issue---I'm not worried about "malicious > code" messing me up. I'm simply trying to juggle the minimum number of > factors on my precious brainstack, and when I'm trying to get a mapped > array, I really don't want to think about whether `map` is going to mess > with my `this`. > > _______________________________________________ > 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
