arrow function syntax simplified

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Apr 2 15:25:05 PDT 2012


On Apr 2, 2012, at 12:47 PM, Brendan Eich wrote:
>> ...
> 
> We had an agreement last year in TC39 to avoid making new shorter function syntax implicitly freeze where the new shorter syntax falls in full function syntax's general body-plan. This was the impetus for the # prefix, which also can apply to object and array literals.
> 
> We're not going to implicitly freeze arrows. It was never in the strawman, or on the whiteboard during the negotiations.
> 
> I agree that leading |this| could be important for dynamic non-method use-cases, but those are relatively rare (let's not discount JQuery, but again, it could use long functions and survive). We could put leading-this-parameterization on the agenda for May, but we'll have to be careful not to lose consensus on arrows.

Other than the JQuery style misuse of this, what are the use cases? If you want to bind this, why wouldn't a method invocation on an objet be involved?


No doubt I'm repeating myself fro a previous message, so I'll be more forceful.  "dynamic this" is a core OO concept but "dynamic this" in a non-method context is an abomination.  A non-method "dynamic this" is essentially a leak in   the implementation of the  object abstract.  This leak is an extreme source of confusion among JS programmers.  We shouldn't be adding things that expand the potential for confusion.  Allowing the this keyword as a formal parameter of arrow functions would be terrible from that perspective.

With concise methods and arrow functions we have an opportunity to cleanly separate the most common definitions of methods and regular (non-method) functions.  You should  use concise methods in object literals (and hopefully class definition) when you are actually defining a method and need to reference the this keyword..  You should use an arrow function in most non-method situations.  For corner cases, legacy libraries, and legacy programmers long form function declarations/expressions are still available. 

There are two abnormal situations that we should consider: calling a "concise method" without providing a this value and calling an "arrow function" in a manner that explicitly provides a this value (other than undefined).  I need to think more about this, but perhaps we should throw in those situations.  For example:

let obj = new class(
     bar() { /* do something useful */}
     foo () {this.bar()}
};
let f = arg => doSomething(arg);
let FOO=obj.foo;

//normal usage
obj.bar();
obj.foo(42);
obj.bar.call(obj);
obj.foo.apply({bar() {doSomethingElse()},[42]);
f();
f.call(undefined,42);

//potential, straightforward runtime errors
FOO(42);         //could be error, trying to call a method without providing a this value
f.call(obj, 42);  //could be error, trying to pass a this value to an arrow function

//less straightforward possible errors
obj.callback = f;  //logically a data property storing a function not a method
obj.callback((42);  //could be error trying to call a arrow function as a method, but the intent may be:
(0, obj.callback)(42); //never an error, not a method call or:
(f=>f(42))(obj.callback);  //never an error,normal call of an arrow function

I see potential value in dynamic errors for the straightforward cases, however the conceptual ambiguity (either a method call or call of functional value retrieved from an object) of obj.f() may be enough to kill the idea.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120402/5fde11b8/attachment-0001.html>


More information about the es-discuss mailing list