Return to Answer

The description of Scala's val and var were backwards

edit approved Aug 9, 2011 at 0:57

The principle benefits of "final" in my mind are two-fold:

Final variables are "safer" than non-final variables, because once they are bound there is never a question about what their current state is.
Because of the above, making a variable final relieves the programmer of excess mental juggling - he/she doesn't have to scan through the code to see if the variable has changed. This happy state-of-affairs will be familiar to anyone who has spent any time in a functional-language setting.

As for this specific example, it may be that the programmer picked up the "final" habit and just applies the "final" keyword everywhere as a matter of course. (I am skeptical of the notion that the final keyword would help the compiler when talking about individual assignments -— surely it doesn't need the help to determine only one assignment took place?)

I'm of the opinion that Java got it backwards -— there should be no "final" keyword for variables, everything should be "final" by default, and if you want a mutable variable you should have to add a keyword for that ("var" or some such). (As another commenter mentioned, scala has two keywords - "var" and— "val" and "var" for final and non-final variables, respectively - I'll take it).

The principle benefits of "final" in my mind are two-fold:

Final variables are "safer" than non-final variables, because once they are bound there is never a question about what their current state is.
Because of the above, making a variable final relieves the programmer of excess mental juggling - he/she doesn't have to scan through the code to see if the variable has changed. This happy state-of-affairs will be familiar to anyone who has spent any time in a functional-language setting.

As for this specific example, it may be that the programmer picked up the "final" habit and just applies the "final" keyword everywhere as a matter of course. (I am skeptical of the notion that the final keyword would help the compiler when talking about individual assignments - surely it doesn't need the help to determine only one assignment took place?)

I'm of the opinion that Java got it backwards - there should be no "final" keyword for variables, everything should be "final" by default, and if you want a mutable variable you should have to add a keyword for that ("var" or some such). (As another commenter mentioned, scala has two keywords - "var" and "val" for final and non-final variables, respectively - I'll take it).

The principle benefits of "final" in my mind are two-fold:

Final variables are "safer" than non-final variables, because once they are bound there is never a question about what their current state is.
Because of the above, making a variable final relieves the programmer of excess mental juggling - he/she doesn't have to scan through the code to see if the variable has changed. This happy state-of-affairs will be familiar to anyone who has spent any time in a functional-language setting.

As for this specific example, it may be that the programmer picked up the "final" habit and just applies the "final" keyword everywhere as a matter of course. (I am skeptical of the notion that the final keyword would help the compiler when talking about individual assignments — surely it doesn't need the help to determine only one assignment took place?)

I'm of the opinion that Java got it backwards — there should be no "final" keyword for variables, everything should be "final" by default, and if you want a mutable variable you should have to add a keyword for that ("var" or some such). (As another commenter mentioned, scala has two keywords — "val" and "var" for final and non-final variables, respectively - I'll take it).

Source Link

answered Aug 5, 2011 at 5:56

nerdytenor

The principle benefits of "final" in my mind are two-fold:

Final variables are "safer" than non-final variables, because once they are bound there is never a question about what their current state is.
Because of the above, making a variable final relieves the programmer of excess mental juggling - he/she doesn't have to scan through the code to see if the variable has changed. This happy state-of-affairs will be familiar to anyone who has spent any time in a functional-language setting.

As for this specific example, it may be that the programmer picked up the "final" habit and just applies the "final" keyword everywhere as a matter of course. (I am skeptical of the notion that the final keyword would help the compiler when talking about individual assignments - surely it doesn't need the help to determine only one assignment took place?)