Obviously the milage varies a lot in this. I can't recall chasing any bugs originating from missing final. I have chased a bug where arrays has been modified or reused, but final doesn't prevent that. I am still -1 to introduce this all over the place. Show me a real bug which could be prevented by a final method argument or final local variable. -- Niclas
On 5/25/08, Michael Hunger <[EMAIL PROTECTED]> wrote: > Thank David I couldn't agree more. It denotates and communicates which > parameter/local variable _references_ are immutable and should not be > reassigned/reused which is a common and hard to find problem (e.g. typo) > if you reuse params/local variables. I spend many hours looking for this > kind of errors in different codebases and have to say that I rather > spend these hours writing productive code :). > > It also stresses the query character of many functions (side effect > free). If you combine this with real immutable parameters and variables > you have a consistent immutability. With some VMs you help the garbage > collector and hotspot when using final, but imho the current Sun JVMs > don't need that anymore if you enable escape analysis. > > Having the compiler complaining this (or rather the IDE) is quite > convenient. > > I also use final on foreach iterator values. > > I'd rather have this as the default in the language and explicitly mark > non final stuff but thats to late by now :). > > Michael > > David Leangen schrieb: >>> I must say that I have never understood the "final" on method >>> arguments. It doesn't bring any value. If the method argument is a >>> native type, I can change it as much as I want as it doesn't modify >>> the caller's value. If the argument is a mutable object, "final" >>> doesn't stop me from modifying the object, only the reference which in >>> turn doesn't affect the caller. Similar for local variables. And IMHO, >>> "final" adds a lot of clutter everywhere. I like using "final" where >>> it makes a difference, not out of principle. -- Cheers, Niclas. >> >> The point is that unless you can _guarantee_ that parameters are >> immutable, >> then a lot of damage and bad side effects can happen during a method call. >> >> The simplest way of adding an extra layer of protection is to simply add >> "final" to the method param. That way you know for sure at compile time >> (i.e. more brainless stuff to take a load off all the already existing >> complexity in the system) that you're not causing any side effects. >> >> >> YMMV, but I've found that once you get used to "final", you don't even >> notice it anymore. In fact quite the opposite: you notice more when it's >> _not_ there (which I guess is the whole point of having it in the first >> place). >> >> >> Cheers, >> Dave >> >> >> >> _______________________________________________ >> qi4j-dev mailing list >> [email protected] >> http://lists.ops4j.org/mailman/listinfo/qi4j-dev > > > -- > Michael Hunger > Independent Consultant > > Web: http://www.jexp.de > Email: [EMAIL PROTECTED] > > Enthusiastic Evangelist for Better Software Development > We support Software Engineering Radio (www.se-radio.net) > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Sent from Gmail for mobile | mobile.google.com _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
