commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Benedict <pbened...@apache.org>
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 Mon, 27 Oct 2014 01:27:32 GMT
Even I must admit that the use of "final" here is more of a formality than
a necessity. I believe that's why it's been called a "stylistic" commit.
The compiler isn't driving you to use it for what you need to accomplish,
and there is no pressing technical need to use it aside from it enforces
something you don't like. The current code works just fine with or without
"final" in this commit, which is why I do consider it to be more of a
personal style than anything else.

Cheers,
Paul

On Sun, Oct 26, 2014 at 8:04 PM, Gary Gregory <garydgregory@gmail.com>
wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message