arrow function syntax simplified

Angus Croll anguscroll at gmail.com
Sun Apr 8 10:22:13 PDT 2012


>
> I don't see anything that is broken by arrow functions.  You are
> attempting to use arrows for defining methods which is incorrect.
>

Sorry, I obfuscated unnecessarily by making the inner functions into arrows
too.
But the important one is the withCircleUtilsFat function which is not a
method

This would have been clearer

var withCircleUtilsFat = () => {
  this.area = function() {return this.radius * this.radius * Math.PI};
  this.diameter = function() {return this.radius + this.radius};
}




> This would be correct:
>
>     function withCircleUtils() {
>         this.{
>           area() { return this.radius * this.raduis * Math.PI; },
>           diameter() { return this.radius + this.radius; }
>         };
>     }
>
> Do you see a problem with this construction?
>


To reiterate: I am forced to use a long-form for withCircleUtils because we
attached special meaning to the short-form. I think the criteria as to when
to use short vs long-form will be unclear to many users and I can already
see a future Good Parts equivalent suggesting "avoid arrows because the
rules of when to use them are unnecessarily complex". Switching to soft
lexical binding would remove these usage constraints. Indeed they would
also allow arrow functions to define methods without resorting to the
unwieldy initial 'this' argument proposal.

Bottom line: is the primary goal of arrow functions brevity or hard-lexical
binding? If its the former (and even if it isn't a lot of dvelopers will
percieve it as such) then we should be careful not to add usage caveats.

Angus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120408/a6322b62/attachment.html>


More information about the es-discuss mailing list