Effectively final effective?

[Reinier Zwitserloot]

On Thu, Feb 25, 2010 at 9:26 PM, John Nilsson <john at milsson.nu> wrote:

> Just to add to the noise. I strongly disagree. The implicit copy is the
> most natural and intuitive semantics of closures in Java IMHO.
>
>
I don't think silently making a copy is intuitive. Which disproves that it
is intuitive in the first place. Instead of saying things are "intuitive"
without explaining why, perhaps try some arguments that aren't based on gut
feeling.

Getting rid of "final" just to save some keystrokes sounds very bad to me.
> This is one of the best keywords in the language!
>

I think you're confusing "keyword" with "feature". If you actually meant the
keyword, presumably your later spiel about how "final" is useful to you
because it indicates a local variable declaration, you're not making a
consistent argument. In that same spiel you point out that your IDE has
fancy colouring capabilities. One of the many capabilities you can build
into any IDE is for it to highlight certain constructs. Such as variable
declarations.


> However when it comes to local variables I demand from everyone in my team
> to always declare every single one of them final.
>

Good lord. Glad that I don't work for you. Do you force your team to write
"java.lang.String" instead of just "String" too?


> To me it is bad style to use mutable local variables unless you have a damn
> good reason for it.
>

for (int i = 0; i < 10; i++) {
    ...
}


And most of the times, you don't. [have an excuse to make a local variable
> non-final]
>

Balderdash. What's even more amazing is that you think the keyword 'final'
is a good idea in the first place, if you've marked 95%+ of all your
parameters and local variables with it. That's some awesome amount of noise
right there. Stuff being final by default and requiring a keyword to make
them non-final is effectively what we're debating here, so you're not making
much sense.

This policy makes code easy to read and maintain.
>

I disagree. A casual glance at thousands of open source java projects
indicate I'm certainly not the only one. Let's hypothesize that you're on to
something. This notion hasn't seeped very far through the greater java
community yet, and now you are advocating that new language design features
should presume everyone feels and codes the same way. I take it you now
realize this is ridiculous.