A few arrow function specification issues

Taka Kojima taka at gigafied.com
Sat Apr 21 13:28:46 PDT 2012


>
> 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 <
domenic at domenicdenicola.com> wrote:

> > -----Original Message-----
> > From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
> > bounces at mozilla.org] 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
> 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/20120421/454c518c/attachment.html>


More information about the es-discuss mailing list