commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sawle <jamessa...@hotmail.com>
Subject Re: Use of final modifiers - WAS svn commit: r1632171 [1/20] - in /commons/proper/beanutils/trunk/src: main/java/org/apache/commons/beanutils/ main/java/org/apache/commons/beanutils/converters/ main/java/org/apache/commons/beanutils/expression/ main/java/org/apache/commons/beanutils/l...
Date Tue, 28 Oct 2014 08:16:30 GMT
I have no view on the use of final modifiers on variables within methods; however on the parameters
I think it is very important so that the code self documents to the caller the behaviour that
they should expect. Recently I was bitten by a library that I was using in a multithreaded
application that was modifying the values I sent it, even though from the contract there seemed
no reason for this. Using the final modifier will give that guarantee, without having to add
it to the Javadoc and definitely without having to look at the source, which no one apart
from a contributor should ever HAVE to do!

Sent from my iPhone

> On 28 Oct 2014, at 07:21, Benedikt Ritter <britter@apache.org> wrote:
> 
> I agree with Oliver. This change is just of cosmetic value and makes it
> harder to apply patches (the same applies for the "sort methods in abc
> order" changes IMHO).
> If we come to the consensus that we want a final key word everywhere, we
> should add that to our code analysis tools configuration. For now, I don't
> feel like we have consens about that.
> 
> Benedikt
> 
> 2014-10-28 1:24 GMT+01:00 Ralph Goers <ralph.goers@dslextreme.com>:
> 
>> Gary does have a passion for these kinds of changes.
>> 
>> I am definitely +0 on them but Gary has taken the initiative to make the
>> changes to Log4j and has continually sought to keep them up to date even
>> though the rest of us don’t really care. We had this same discussion a
>> while ago on that mailing list.  The conclusion I came to is that the final
>> keyword has value on class attributes and some value on parameter
>> declarations and has value only in special cases inside of methods.
>> 
>> I do know there are cases where the compiler takes advantage of the
>> declaration.  I also know that occasionally I have to remove the final
>> keyword because I want to modify the value of a local variable.  I really
>> dislike them in unit tests.
>> 
>> Personally I think the way to go is to come to a consensus on where they
>> are required, where they are optional, and where they should not occur.
>> 
>> Ralph
>> 
>> 
>> 
>>>> On Oct 27, 2014, at 1:44 PM, Oliver Heger <oliver.heger@oliver-heger.de>
>>> wrote:
>>> 
>>> 
>>> 
>>>> Am 27.10.2014 um 02:04 schrieb Gary Gregory:
>>>> On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <
>> oliver.heger@oliver-heger.de>
>>>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>>> Am 24.10.2014 um 22:47 schrieb Mark Thomas:
>>>>>>> On 24/10/2014 21:17, Oliver Heger wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> Am 24.10.2014 um 22:01 schrieb Gary Gregory:
>>>>>>>> On Fri, Oct 24, 2014 at 3:23 PM, Oliver Heger <
>>>>> oliver.heger@oliver-heger.de>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Am 23.10.2014 um 22:58 schrieb Gary Gregory:
>>>>>>>>>> Patches go stale no matter what...
>>>>>>>>> 
>>>>>>>>> Right, this can happen during normal development, but
not
>> necessarily
>>>>>>>>> because of a big bang change for which there is no technical
>> reason,
>>>>> but
>>>>>>>>> which is just a matter of personal taste.
>>>>>>>> 
>>>>>>>> I call it a technical reason, you call it personal taste,
we are not
>>>>> going
>>>>>>>> to agree.
>>>>>>> 
>>>>>>> Obviously not. So how do we proceed?
>>>>>> 
>>>>>> You work it out until a consensus is reached and then that consensus
>> is
>>>>>> implemented. The more entrenched folks are in their positions, the
>>>>>> longer consensus is going to take. (And no, a VOTE is not the right
>> way
>>>>>> to resolve this.)
>>>>>> 
>>>>>> My own view is that the addition of the final keywords does have
>>>>>> technical merit. Not enough to make me want to spend the time to
fix
>> the
>>>>>> projects I work on, but I wouldn't complain if someone else wanted
to
>>>>>> make all the necessary changes. Similarly while I think it would
be a
>>>>>> shame to throw away all this good work, I could live with that option
>> if
>>>>>> that was the consensus opinion.
>>>>>> 
>>>>>> The issue of out-dated patches is a red herring. That is a separate
>>>>>> problem. The community needs to apply / review patches faster.
>>>>>> 
>>>>>> Mark
>>>>> 
>>>>> Okay, so back to discussion.
>>>>> 
>>>>> First of all I have to state that I am irritated about the way this
>>>>> change was done. It is really an invasive commit without any prior
>>>>> announcement. For a collaborative project I do not consider this as
>> good
>>>>> style. As some replies to this thread show, there is no consensus about
>>>>> the changes performed.
>>>>> 
>>>>> As an example on the same level,
>>>> 
>>>> 
>>>> This is a silly example IMO because you talk about using a Windows C
>>>> _naming_ convention in Java, which has zero effect on compiled code,
>> while
>>>> we are talking about using a Java language feature which does matter to
>> the
>>>> compiler. Apples and Oranges.
>>> 
>>> Not in the sense that both changes aim at making code more
>>> understandable without having any impact on functionality.
>>> 
>>>> 
>>>> 
>>>>> I could come to the idea that I prefer
>>>>> variable names with special prefixes. In C programming under Windows
>>>>> there was a convention of adding prefixes to variable names derived
>> from
>>>>> their data type: String sName, int iCount, Double[] adNumbers, etc.
>> What
>>>>> could argue that this makes code more understandable because each
>>>>> variable carries meta-information with it. If I suddenly started to
>>>>> rework the code of multiple components based on this convention, I
>> would
>>>>> surely trigger some reactions.
>>>>> 
>>>>> IIUC, the purpose behind this change is to make the intension of the
>>>>> programmer explicit that a specific variable is not going to be
>> changed.
>>>> 
>>>> It is that, and more. Just as important and perhaps more so: When I read
>>>> code or I am stepping in a debugger and I see a 'final' I know that a
>> value
>>>> is not going to change from under my feet. I can put that aside as a
>>>> variable (pun intended) in my mind and worry about other aspects of the
>>>> code.
>>> 
>>> The vast majority of Java code I encounter does not use final modifiers
>>> in this way (I know, it is your mission to change this). Therefore, when
>>> I see a final I ask myself what is the special purpose here? Is it
>>> referenced by an anonymous class?
>>> 
>>> The information whether a variable cannot be changed has not been that
>>> important for me; this can easily be spotted from the context: if there
>>> is an assignment, well it is changed. Otherwise, your method is probably
>>> too complex and needs refactoring.
>>> 
>>> Oliver
>>> 
>>>> 
>>>> Gary
>>>> 
>>>> 
>>>>> I doubt that you manually inspected the whole code base. Rather, I
>>>>> assume you used a tool - Eclipse has a corresponding option - which
>>>>> analyzed all possible code paths to determine whether a variable can
be
>>>>> final. This does not tell too much about the intentions of the original
>>>>> authors. Further, when using such a tool there is not much intellectual
>>>>> work behind this. Please correct me if I am wrong here.
>>>>> 
>>>>> From my perspective the excessive use of final modifiers makes code
>>>>> harder to read because it adds so much noise. There are some places
>> when
>>>>> Java requires the use of final; but those special places which may be
>> of
>>>>> interest are now completely hidden in the overall final fog.
>>>>> 
>>>>> Oliver
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:
>> dev-unsubscribe@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
>> dev-help@commons.apache.org>
> 
> 
> 
> -- 
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
Mime
View raw message