Re: Why must and must not be "final" ?
Andreas Leitgeb wrote:
Mark Rafn <dagon@dagon.net> wrote:
Andreas Leitgeb <avl@logic.at> wrote:
class Outer {
final TextField[] tf = new TextField[1];
...
}
This isn't necessary for member variables. Just make them non-final and all
is well. It's an ugly but effective workaround when an anonymous inner class
needs access to local variables or parameters that you want to change.
trapped.
I mixed up the context while writing the followup.
I meant:
void myFunc() {
final TextField[] tf = new TextField[1];
new Object() { void foo() { tf[0]=<whatever>; } }.foo();
// now tf[0] is <whatever>.
}
AtomicReference appears to me like overkill in this respect,
since we're talking about local variables, that are "rarely"
(that is: never ever) shared among threads...
This method seems bad. If an anonymouse-inner class has to modify some
state somewhere, have it call a method to do so, or make it
non-anonymouse, and have it have its own state.
void myFunc() {
new Object() {void foo() {setTextField(<whatever>); } }.foo()
}
or
class Outter {
static class MyFooable {
TextField textField;
void foo() {
textField = <whatever>;
}
}
void myFunc() {
MyFooable mf = new MyFooable();
mf.foo();
TextField textField = mf.textField;
}
}
------------------------
In any case, I consider it best practice to have all variables final if
possible, and parameters final only if necessary (although there is an
argument to having them all final).
If you can't make a variable final, make sure that you couldn't just
use different final variables instead of one variable repeatedly. It
makes code less confusing, and there really isn't a benefit to re-using
the same variable over and over, unless it is an accumulator of some
sort.
(sum += value, for instance)
Hope this makes sense.
- Daniel.