Whilst with primitives it is call by value with objects it is not, and whilst the final modifier does not stop a method from changing an internal value, it is acknowledgement that they won't, read writings by Joshua Bolchdku h m
Sent from my iPhone > On 28 Oct 2014, at 08:55, Bernd <e...@zusammenkunft.net> wrote: > > Hmm, > > You know that Java has no out variables (as it is call by value) and the > final identifier does not make an object read only. So in fact having final > modifiers would misslead you even more. > > Actually I like having final fields and variables (for example it avoids > unneeded initialisation). On the parameters I feel it makes the signatures > unreadable long, and given that stylistic warnings about Ssigning > parameters happen in Eclipse anyway I dont need them. (But I dont mind if > used). > > Greetings > Bernd > Am 28.10.2014 09:17 schrieb "James Sawle" <jamessa...@hotmail.com>: > >> 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 <brit...@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.go...@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.he...@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.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. >>>>> >>>>> 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-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 >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org <mailto: >>>> dev-unsubscr...@commons.apache.org> >>>>> For additional commands, e-mail: dev-h...@commons.apache.org <mailto: >>>> dev-h...@commons.apache.org> >>> >>> >>> >>> -- >>> http://people.apache.org/~britter/ >>> http://www.systemoutprintln.de/ >>> http://twitter.com/BenediktRitter >>> http://github.com/britter >>
