Weird const in the arrow functions demo

[codepo8]

You're defining the double in the last example as a const, however it gets changed on every application of the map. let would make more sense, wouldn't it?

[exogen]

It's not really getting changed though on each call since each call has its own scope within the function; the declarations don't "carry over" on each call. eslint would actually warn you of an unnecessary use of let.

[codepo8]

True, it does seem to be an odd use of const though as it is never re-used. Maybe a simple var should do the trick. It's not a mistake, but it seems a weird use, seeing that defining a const is a statement of "this won't change"

[exogen]

I'd personally change the whole function to return number * number * number; myself, the separate declaration is indeed kinda confusing no matter how it's declared. But FWIW, eslint would warn of var as well since it recommends only let or const.

[codepo8]

I agree with that option. Much less contrived. Or to make it shorter return
Math.pow(number, 3)

On Tue, Oct 13, 2015 at 1:17 AM, Brian Beck notifications@github.com
wrote:

I'd personally change the whole function to return number * number *
number; myself, the separate declaration is indeed kinda confusing no
matter how it's declared. But FWIW, eslint would warn of var as well
since it recommends only let or const.

—
Reply to this email directly or view it on GitHub
#11 (comment)
.

[divmain]

number * number * number is definitely better. However:

seeing that defining a const is a statement of "this won't change"

It's a bit more nuanced than that. const is really a statement of "this won't be reassigned within the context of this block, and specific to this invocation". Thinking of a const in terms of "this won't change" can lead to incorrect assumptions. For example, const a = {}; a.val = true; is perfectly valid - a is not reassigned in this case, but the object that a references can change.

In the arrow-function example, const should be preferred over var (even though the line itself is unnecessary) because a's assignment doesn't change within the context of each invocation. In fact, I would argue that there is no longer a need to use var anywhere, assuming an ES2015+ environment.