Is there a reason why the author is referring to them as fat arrow functions instead of lambdas? I am not trying to be snarky, this is genuine curiosity if there is something differentiating.
Fat arrow functions in Javascript
41–48 of 48 posts
Re: Fat arrow functions in Javascript
#42So let me get this straight... a whole new function syntax is being introduced, just to replace:
var that = this;
var f = function() {
return that.x;
}
var f = () => {
return this.x;
}
JavaScript is already tricky enough to keep track of everything having to do with "this", now they're adding extra complexity to that too by having multiple types of functions that treat "this" even more differently? (Since it's not like they're removing the original behavior...)
Re: Fat arrow functions in Javascript
#43Re: Fat arrow functions in Javascript
#44Is this syntax part of ECMAScript 6? I.E. will it eventually be supported by all browsers?
If you want to use it now and get full browser support, you can use the TypeScript compiler, which will compile into ES3 or ES5 targets. It also supports ECMAScript 6's classes syntax.
It's pretty neat to use this tech now on production sites and not having to worry about browser support.
http://en.wikipedia.org/wiki/TypeScript#ECMAScript_6_support
Re: Fat arrow functions in Javascript
#45Is there a reason why the author is referring to them as fat arrow functions instead of lambdas? I am not trying to be snarky, this is genuine curiosity if there is something differentiating.
If you recall, a lambda is just an anonymous function which javascript already has.
//an example of a self-executing anonymous function
(function(x) { return x * x; } (3)); //returns 9
arrow functions are a bit different in that:
* It has Lexical this (normally fixed in usual functions via closure or .bind())
* this cannot be redefined
* arrow functions cannot be used as a constructor
* arrow functions are always anonymous
See also: http://wiki.ecmascript.org/doku.php?id=harmony:arrow_functio...
Re: Fat arrow functions in Javascript
#46Earlier quoted context omitted.
I was aware it's pretty modern but honestly didn't think about it much. We use it heavily in Firefox Devtools code and I much prefer its non-hoisting properties over var.
Out of curiosity, what do you mean by non-hoisting properties? According to the MDN docs let variables are hoisted, at least to the enclosing block.
I usually think of "hoisting" as promoting a var outside of its containing scope to within the next block.
e.g.,
function() { var a = 2; // b is visible here if (a == 2) { var b = 3; } }
Re: Fat arrow functions in Javascript
#47Earlier quoted context omitted.
Out of curiosity, what do you mean by non-hoisting properties? According to the MDN docs let variables are hoisted, at least to the enclosing block.
I usually think of "hoisting" as promoting a var outside of its containing scope to within the next block. e.g., function() { var a = 2; // b is visible here if (a == 2) { var b = 3; } }
Hoisting still occurs within a scope such that, for example, a function defined at the end of a block can be called at the top.
Re: Fat arrow functions in Javascript
#48Earlier quoted context omitted.
I usually think of "hoisting" as promoting a var outside of its containing scope to within the next block. e.g., function() { var a = 2; // b is visible here if (a == 2) { var b = 3; } }
Hoisting still occurs within a scope such that, for example, a function defined at the end of a block can be called at the top.
right. The point I was trying to illustrate was that the inner variable declared with a "var" keyword was visible outside its containing block. If I'd used "let" there, it would not be.