A few arrow function specification issues

Angus Croll anguscroll at gmail.com
Sat Apr 21 13:38:17 PDT 2012


>>a function shouldn’t work radically (and silently!) different depending
on how it is invoked

every current JS function behaves exactly this way :-)

I'm painfully aware that I sound like a broken record on this, but
introducing a hard-bound function option while continuing to suport
dynamic-bound functions everywhere else is not going to simplify anything.
Another function should not need to know how its function arguments were
created in order to work properly - thats a terrible anti-functional
anti-pattern!

Imagine....

function(fn) {
//....
  if (fn.prototype) {
    fn.apply(x);
  } else {
    throw Error("I can't call your function in my context");
 }
}

On Sat, Apr 21, 2012 at 1:28 PM, Axel Rauschmayer <axel at rauschma.de> wrote:

> I am in agreement with Angus on this one.
>
> If there is no skinny arrow, hard |this| binding should not be part of the
> spec. Fat arrow functions should default to lexical |this|, but if there is
> no skinny arrow, it should not be a hard binding and call/apply should be
> allowed, as well as bind,
>
>
> IMHO, the spec got it exactly right. We have a chance to really simplify
> things and introduce a clear distinction:
>
> - Methods – dynamic `this`: Use a concise method definition inside an
> object literal (or, hopefully, inside a class declaration).
> - Non-method functions – lexical `this`: Use an arrow function.
>
> Anything else is rare (see Kevin Smith’s JS code survey) and non-methods
> with dynamic this are usually an anti-pattern. If you really need it, there
> are always old-school functions.
>
>
> As for switching between dynamic `this` and lexical `this` depending on
> whether a function is called as a method or as a function. At first glance,
> it sounds like a good idea, like the best of both worlds. However, I’m with
> Domenic Denicola: it’s too brittle – a function shouldn’t work radically
> (and silently!) different depending on how it is invoked. Switching to this
> = undefined is bearable for old-school non-method functions, but switching
> to lexical this will lead to many hard-to-debug errors.
>
> --
>        Dr. Axel Rauschmayer
> axel at rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120421/b7c0a9f7/attachment-0001.html>


More information about the es-discuss mailing list