Effectively final effective?

[John Nilsson]

I think we just disagree ;-)

On Thu, Feb 25, 2010 at 10:26 PM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

> 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.
>
Which would be the IMHO part of that statement. For arguments I refer to
earlier mail from Artur Biesiadowski. But as an example, it is already
possible, and at least to me perfectly intuitive, to write for(final T t :
ts).


> 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.
>
Consistent or not, it's my take on the issue. And as always, YMMV. Yes you
are correct that this is possible. But as it stands now, it is not
necessary, I get two features at the cost of one. Immutability and
visibility.



> 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?
>
Of course not. And if you think that is comparable maybe you misunderstand
me. It is not simply for the syntax. By demanding immutability you also
force people to think about what they are doing and write somewhat coherent
code. And as with all rules, there are exceptions of course. YMMV but it
works for us.


>  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++) {
>     ...
> }
>
This is one of those odd examples that actual works fine despite mutability.
But it is the same as with method arguments. You don't expect people to do
stupid things like mutate i inside the body of the loop. Also, if you have
the need for this construct you are either doing something wrong, or are a
sufficiently competent coder to know what you are doing, in which case I
trust you to write good code from the beginning.


> 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.
>
If that was the case I would support it wholeheartedly. Replacing final with
mutable across the language works fine with me. This is not what is being
discussed though, what is being discussed is an isolated exception to the
general syntax of the language.

One of the reasons I like Scala is for the symetry of val/var/def  three
simple letters for each construct. In Java you instead have either fairly
long or no keyword at all, and I happen to dislike the no-keyword version.


> 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.
>
Even if this notion hasn't spread throughout the Java world yet. The general
notion of immutability seems very accepted in the functional world, and it
looks like it is gaining traction as a result of the concurrency
preparations taking place everywhere.

I simply present a data point to highlight that there are radically
different opinions from yours on this matter (but it can't be that radically
different because I actually like project Lombok). I am fully aware that I
am just that, one data point.

 BR,
John