“Arrow is not a replacement for all functions that want lexical this”
I can't remember the example I used in the meeting, but one example is a recursive function:
class Chicken extends Weapon {
constructor(length, elasticity, initialVelocity) {
this.length = length;
this.elasticity = elasticity;
this.initialVelocity = initialVelocity;
var self = this;
function animate() {
...
self.velocity
self.elasticity
self.length
...
setTimeout(animate, n);
...
}
...
}
}
The point I was making in the meeting was that arrow functions are a syntactic convenience for a common case, not a general-purpose replacement for all functions that need to refer to an outer this-binding. They are not general-purpose because they don't support all the features of longhand functions.
The point I was making in the meeting was that arrow functions are a syntactic convenience for a common case, not a general-purpose replacement for all functions that need to refer to an outer this-binding. They are not general-purpose because they don't support all the features of longhand functions.
I agree, and would go farther: at a conceptual level arrow functions represent lightweight functional mappings. We should avoid any desire which would muddy that concept.
I can't remember the example I used in the meeting, but one example is a recursive function:
I don’t see the problem. Would the following code not work?
const animate = () => {
...
this.velocity
this.elasticity
this.length
...
setTimeout(animate, n);
...
};
The point I was making in the meeting was that arrow functions are a syntactic convenience for a common case, not a general-purpose replacement for all functions that need to refer to an outer this-binding. They are not general-purpose because they don't support all the features of longhand functions.
Given that function names will probably be inferred by engines, only hoisting would be an advantage of a hypothetical longhand function with lexical this(?)
What I’m worried about is conceptual simplicity. I like function declarations and prefer them to function expressions, but recently did a small survey on Twitter and was surprised to find out that the majority of people prefer var + function expression to a function declaration, because then there is only a single kind of function definition.
Axel Rauschmayer wrote:
... was surprised to find out that the majority of people prefer var + function expression to a function declaration, because then there is only a single kind of function definition.
Small-N survey, right? Opinios vary widely. However, try a code search
for var [A-Za-z_][A-Za-z_0-9]* = function vs. function [A-Za-z_].
The latter predominates (of course this leaves out other uses of
'function').
On Dec 9, 2013, at 12:36 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
What I’m worried about is conceptual simplicity. I like function declarations and prefer them to function expressions, but recently did a small survey on Twitter and was surprised to find out that the majority of people prefer var + function expression to a function declaration, because then there is only a single kind of function definition.
My only point was that in general, arrow functions will not completely replace longhand functions. It may be the case that for some programmers, even many (though I'm skeptical), they will. They won't in general.
Brendan Eich wrote:
I don’t see the problem.
You're right, the example that wants function would need hoisting, e.g.:
function even(n) {
return n === 0 || odd(abs(n) - 1);
}
function odd(n) {
return n !== 0 && even(abs(n) - 1);
}
But even here, before the first call to either, you might arrange to bind even and odd before any call to either (including from within the other).
Still, the Web has code that relies on hoisting. At a minimum, it's pleasant in JS to be able to write a "literate program" in top-down order, with forward calls to later function declarations.
FWIW, function [A-Za-z_] includes var expr = function expr() {} or
{expr: function expr(){}} both quite common patterns (the first one when
you want to be able to debug the name of the function but due inline, later
on, features detection, the former might change)
Still I agree with David and asked again indeed what was the rationale for arrow function that in my opinion solves only one very specific case and nothing else ... came out in CoffeeScript that is the most common case (I don't even understand why is that but ... hey, I don't CoffeeScript so I believe that's OK)
Andrea Giammarchi wrote:
FWIW, function [A-Za-z_] includes
var expr = function expr() {}or{expr: function expr(){}}both quite common patterns (the first one when you want to be able to debug the name of the function but due inline, later on, features detection, the former might change)
Sure, I wasn't giving the exact regexen required for distinguishing cases of NFEs from FDs, if you get my abbreviations :-).
Still I agree with David and asked again indeed what was the rationale for arrow function that in my opinion solves only one very specific case and nothing else ... came out in CoffeeScript that is the most common case (I don't even understand why is that but ... hey, I don't CoffeeScript so I believe that's OK)
Don't keep asking for rationales (a) that are already given, and (b) that you don't like (whether they have objective groundings -- this one does -- or not). We've been over this a zillion times. Didn't I already refer you to Kevin's quantitative analysis in the last thread from October?
esdiscuss.org/topic/what-kind-of-problem-is-this-fat-arrow-feature-trying-to-solve#content-23
To rehash yet again, with an aggrieved tone, is just you being aggressive for no purpose. Please stop. Arrows are in ES6. Take a deep breath, get over it.
I didn't ask for anything indeed, I was rather pointing out your RegExp search was not so accurate. The rest, once again, I agree with David, rationales or not.
OK this was rough/quick malformed answer ... just realizing it!
Overall, I wasn't complaining about fat arrow and I understand it made through ES6, I just honestly still don't quite get it, and probably ever will, but it was my fault to bring it back as off-topic matter for this thread.
Apologies for the rushed email, my only reasonable point was about not trusting blindly RegExp searches over repositories, somethng most of us know, some lurker might still not consider.
Best
Source: David Herman, rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md
Can someone elaborate? I don’t see an alternative.