[PJUG Javamail] primitive method argument as primitive and final

[Richard]

On Monday 19 February 2007 09:13, Vijay Balakrishnan wrote:
"      void finalInt(final int i) {
"          //i++;//can't change the value of i in this method..Is there any
"  value to using final for i here ?
"      }

My two cents ...  possibly.

You have a void method.  That means you're not setting a value to return to 
your current processing stream.  *That* means you must be changing the state 
of your operations in some way.  What way?  The way told to you by your input 
parameter.

It's easy to conceive of a method that changes the state of your program in a 
way that changes the state of the overall system in a way that wants to 
change the state of some int value somewhere in the program.  Homeostasis, 
for instance.  

"But this is a local variable," you say, "and so will be quickly consumed and 
destroyed."  Possibly.   It's only a local variable if the method decalres 
its own "i" and shadows the input parameter.  (At least in Java.  I don't 
know about c#.)  Since we don't know from the method signature if your 
finalInt() method passes the local copy (or original) on to some other method 
(perhaps embedded in another object or collection) we can't determine a 
priori whether "i" (either one or both) will actually be changed.

By declaring the input parameter final, you guard against side effects, 
especially if your method calls some poorly-docmented code in someone else's 
jar file,   You also document that you're worried about side effects that 
might surprise the state of your software.   Probably not the most effective 
way to guard, and far from the most effective documentation, but nonetheless, 
it's a way.

If the method only has an i++ (as your example shows) and the original writer 
documented a desire to prevent that very kind of operation, we need to look 
further into the program design.  Why did the original author not want the 
state of this (local copy of a) variable changed even though the state of the 
program is changing?   Did the method author really want to shadow the input 
parameter and forget to do so?

Too many questions.  Lots of fun.  :-)  Additonal javadocs make sense here.
-- 
Richard Johnson
(now donning asbestos underware, so flame away)