lib: use arrow functions instead of bind

[JungMinu]

use arrow functions instead of bind(this) in order to improve
performance through optimizations.

[kenany]

I don't think you should touch anything in deps/npm/node_modules/ and tools/eslint/ since they contain third-party dependencies.

[Fishrock123]

Yes, please be sure not to touch anything in deps/ or tools/eslint

[Fishrock123]

@JungMinu instead of making a new PR you can just amend you changes (via git add and git commit --amend) and then force push it to this branch.

[Fishrock123]

@JungMinu actually; even more specific: please only do files in lib/ -- a change to the tests wouldn't be worth the change size I think.

[mscdex]

Looks like the file permissions for the files in deps/ and tools/ are still being changed.

Also, have you done any benchmarking to show before and after these changes? Looking at the diff, I'm not sure that these changes actually affect any hot code paths.

[Trott]

Except for the last sentence, the PR text appears to be copied from https://www.nczonline.net/blog/2013/09/10/understanding-ecmascript-6-arrow-functions/. If you want to use someone else's text verbatim, please remember to cite it.

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/656/

[jbergstroem]

I'd be keen to see that benchmark as well before landing this.

[Trott]

The win here, at least the way I see it, is in readability by getting rid of all the .bind(this) stuff. That's my opinion though. I wouldn't argue with someone else who thought that removing the explicit binding introduced too much magic. (I wouldn't agree, but I wouldn't argue either.)

As noted by @mscdex, none of this looks like it's in a hot path and so I very much doubt any of this will result in a measurable performance boost. Benchmark proving otherwise welcome, but it seems like the benefit here is a the readability/maintainability gain.

[mscdex]

IMHO as far as readability goes, it's about the same, maybe worse (but that would be more of a general ES6 problem).

[jbergstroem]

I guess where I was heading was that if this goes in with "faster" as the commit message it should be properly warranted. Style "fixes" is another category.

[Fishrock123]

bind() is known to be slow, so if nothing else it makes institution faster. I'll look into the perf more, but also cc @trevnorris who originally suggested this kind of change

On Nov 1, 2015, at 6:39 PM, Johan Bergström notifications@github.com wrote:

I guess where I was heading was that if this goes in with "faster" as the commit message it should be properly warranted. Style "fixes" is another category.

—
Reply to this email directly or view it on GitHub.

[trevnorris]

Minus the file permission changes, LGTM. As @mscdex mentioned, it's not an improvement in readability, but that's not what we're going after. In these specific locations there's nothing hot so won't notice a performance gain, but might as well make the change where it makes sense.

[Fishrock123]

@JungMinu I'm not sure you caught every case of .bind() in the files under the lib folder. When I did a search I came up with 111 matches across 32 files. In addition, could you also check for any cases in src/node.js -- that's the only relevant file that is weirdly placed, I think.

Also how did you edit the files? I'm not sure what would have caused those mode changes.

[Fishrock123]

Oh, maybe those mode changes were from previously changing those files..

[Fishrock123]

ok, that search from my windows machine wasn't correct, but using Atom Editor I find 28 results across 7 files for lib/ for .bind(this. (It's possible searching for just .bind( will come up with some other results that could also be replaced, if you're feeling brave.)

Looks like there's nothing in src/node.js.

[bnoordhuis]

Abandoning PRs and refiling them again is kind of annoying because it loses the discussion and the review history (of which there was quite a bit, it looks like.) Can I suggest you do a rebase, fix up the issues and force-push to your existing branch?

[bnoordhuis]

If your implicit question is 'how?', check the documentation for git rebase -i a.k.a. interactive rebase.

[bnoordhuis]

Presumably your editor did something to those files? When in doubt, use vim.

[Fishrock123]

Hmm, A consideration we should make: If there is a obj.send = this.emit.bind(this, 'message') you'd probably call it like: obj.send(mymessage) which would apply as: this.emit.call(this, 'message', mymessage).

If it were possible () => this.emit('message', ...arguments) would work, however, arguments is not exposed in arrow functions.

Ideally we'd have (...args) => this.emit('message', ...args) but rest parameters (The first (...args)) doesn't yet exist..

We could write it as (a,b,c,d,e) => this.emit('message', a,b,c,d,f) but that is potentially not correct, and pretty messy.

@trevnorris Does that sound about right? I think we need to be careful for now.

Rest params come in v8 4.7, so we could just have this target master once that lands, even though it'l be 6 months until it ships then.

[cjihrig]

Rest params come in v8 4.7, so we could just have this target master once that lands, even though it'l be 6 months until it ships then.

There is no rush on this change, right?

[Fishrock123]

There is no rush on this change, right?

@cjihrig Correct. (That being said, it would be nice to have subset in v5 if possible.)

[trevnorris]

@Fishrock123 Currently rest parameters are even less optimized than bind(). Stay away from it. Far away.

[MylesBorins]

Just putting a note here that this commit has still not landed in v5.4.x

[Fishrock123]

Some backstory on that:

1. I screwed up my release tooling for v5.4.0 which missed this commit, and only this commit, since it was the first one in the list.
2. @thealphanerd's Smoke-testing for v5.4.1 seemed to indicate this commit may have an error in it, but my testing afterwords seemed to indicate it was just tape's tests being flaky.

[balupton]

Regarding benchmarks, I'm not sure if the requests were for bind to arrow functions performance in general, or their performance when applied to node's codebase via this PR. For the former, for those interested, there is https://github.com/bevry/esnext-benchmarks which compares performance with several esnext features with the es2015 and other counterparts. Perhaps it will be useful for some readers. If it was the latter, can't help there.