Refactor functions to arrows

[benjamingr]

Another really small one, refactor a bunch of function(...){return ... } into (...) => ....

I considered also changing Client and removing the self = this but as it
is a legacy interface I don't think it's worth the trouble.

[mscdex]

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

[cjihrig]

LGTM pending CI

[thefourtheye]

LGTM

[mscdex]

ARM CI failure is unrelated. I re-ran the linter again since there was a Jenkins failure with it the first time: https://ci.nodejs.org/job/node-test-linter/1004/

LGTM

[Qard]

Do we have a defined code style on parens for single argument arrow functions?

[targos]

I don't think we have one. The eslint rule would be http://eslint.org/docs/rules/arrow-parens.html

[Qard]

I'm happy either way, just wanted to bring it up. :)

[benjamingr]

I'd like to see us specifying these sort of things in one clear way (of course, I don't mind aligning with it).

[rvagg]

Please can we go for always-parens around the arguments when we do these? I find the terseness without them make them harder to visually parse when reading code. I think I might have @cjihrig on my side on this at least.

[benjamingr]

I'm perfectly fine with either (both are readable IMO) but I definitely something that thing should be specified clearly in a coding styleguide.

[benjamingr]

Thanks for the review. Ready to land.

[vkurchatkin]

-1. exporting arrow functions should be a major

[jasnell]

@vkurchatkin ... I tend to agree but can you expand on the reasoning for that

[jasnell]

In fact, reviewing it further, I'm going to pop the LTS watch label off this...

[tomgco]

-1. exporting arrow functions should be a major

I agree,

The context of this can not be changed with bind or call also an exported fat arrow function will also not have a .prototype which might be relied on by implementors.

[jasnell]

going to mark as semver-major defensively for now. That shouldn't stop it from landing tho if we think it's ready :-)

[benjamingr]

I'm going to close this - I wanted to start discussion about the coding style in the files - look like that goal has been achieved.

As we don't have a consensus that arrows are a good idea here I'm going to close this.

(The concerns for a breaking change are unfounded though - the function doesn't use this anyway so there is no change w.r.t bind/call, the only difference is when calling it with new and I doubt anyone ever did that).