Chore: Use arrow functions where possible (lexical this).

[originalfoo]

• Version: 6.2.1
• Platform:
• Subsystem: various

Following on from #7295, I've spotted similar pattern in many other files:

var self = this;
something(someFunc(...) {
  self.whatever();
});

In most scenarios, this pattern can be replaced with an arrow function, allowing removal of 'self' var:

something((...) => {
  this.whatever();
});

I'd like to use this issue ticket as a hub for several commits/PRs relating to this (one changed file per PR, although there may be several commits in the PR - one for each arrow function implemented in the file).

[addaleax]

although there may be several commits in the PR - one for each arrow function implemented in the file

It’s up to the one who creates the PR how they do it, but the commits will very likely be squashed together anyway.

[originalfoo]

@addaleax it's more so I can interactive rebase or cherry-pick should a specific commit need removing etc; just sort of a habit I got in to.

[addaleax]

@aubergine10 As said, it’s up to you. :)

Tbqh, I’d like to hear or work out some kind of rule of thumb of which types of style-only changes are generally considered worthwhile. These kind of changes tend to generate a lot of noise, and while I see that something like #7378 can improve readability noticeably, I’m not sure that’s always the case.

[originalfoo]

@addaleax Ultimately it will probably depend on whether there are any improvements in terms of performance, gc, RAM consumption, etc. I'm not skilled enough to determine whether there are any tangible benefits to replacing the var self... pattern with arrow functions. I imagine the V8 optimising compiler will already seek to avoid creating unnecessary arguments objects, etc?

[addaleax]

I wouldn’t expect any significant performance difference, no.

[originalfoo]

Based on the discussion yesterday I did some googling regarding performance of arrow functions and other ES6 features and found this: http://kpdecker.github.io/six-speed/

If those results are correct, it looks like ES6 features, in general, are currently offering very little benefit over their ES5 counterparts and in many cases result in notably worse performance.

I noticed that the Node.js test scripts include some performance tests but I'm not sure how to extract that data and compare to data from the unmodified scripts... Would be interesting to see what the performance impact is of the current two batches of edits. Without a clear improvement in performance, I don't think there's any benefit to using arrow functions over the ES5 approach.

Another interesting read on arrow functions: https://blog.getify.com/arrow-this/

[Fishrock123]

Arrow functions are great for replacing Function#bind() -- I think we've already done most or all of that though.

[lance]

Heh - so, after submitting a PR for repl.js on this, I decide to read the comments. I'll leave the PR open for now anyway...

Curious that certain arrow operations are slower than ES5 (semi-)equivalents. Without any real understanding of how V8 implements these language features it seems arrow functions should typically perform faster because the runtime doesn't need to allocate a new this or arguments for the function. But that's just napkin scratching.

[jasnell]

Closing. This has been happening incrementally