Rhett Aultman wrote: > It's my understanding that, for certain object types, the compiler can use > "final" designation as a flag for further optimizations and so it actually > might be a wise idea to do. If nothing else, I remember reading an interview > with James Gosling on "object mutability", a compiler optimization whereby a > final object can be decomposed into certain constituents (since it will never > be altered). > > Personally, I just don't use final designations in the way it's shown because > it doesn't occur to me that it's important. ;)
Cocoon is full of "final", basically the same as the C++ use of "const", partly because it allows *all* compilers to do important optimisations, and partly because this let the compiler detect quite a few thinkos and some design flaws. For example, declaring method parameters as final disallows assignments to them, which may force the use of more localized variables, thereby often enhancing maintainability, helping dumb compilers to compile better code and decreasing the compile time for the cleveer compilers which can do proper flow analysis by itself. Another aspect is that it helps in detecting traps like if the parameter is named the same as an instance variable and someone thought he's assigning the instance variable instead of the parameter. There is a lot of literature about when and why using C++ const is an advantage and when not, a large part of this is probably applicable to Java final. I think we should leverage "final" more often in FOP. J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
