On Sat, Oct 25, 2014 at 3:27 PM, Oliver Heger <oliver.he...@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.he...@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 > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
