commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject 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 Sat, 25 Oct 2014 19:27:31 GMT


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, 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.
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


Mime
View raw message