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.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
