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