You're right -- I don't like the academic discussion of "final", because it's
in practicalities
where "final" really shows its power.
Comments intermingled below.
Reinier Zwitserloot wrote:
> If we allow modification in the pre-amble, this is easy, bordering on
> the trivial (lines //V2 have been added/modified in the update):
>
> public List<ConfigDirectives> readConfig(String configKey) {
> configKey = translateOldKeyNames(configKey); //V2
>
> try {
> Logger.get(this.getClas()).log("Request for config file: " +
> configKey);
> return readConfigDirectivesFromDisk(new FileInputStream
> ("configfiles/" + configKey + ".cfg"));
> } catch ( FileNotFoundException e ) {
> return Collections.emptyList();
> }
> }
>
> The one doing the editing really could get away with not even looking
> at what the actual body of the method does. Nice.
>
> Now lets try with your rule:
>
> Urgh. We can't.
Really? What about this?
public List<ConfigDirectives> readConfig(final String oldConfigKey) {
final String configKey = translateOldKeyNames(configKey); //V2.1
try {
Logger.get(this.getClas()).log("Request for config file: " +
configKey);
return readConfigDirectivesFromDisk(new FileInputStream
("configfiles/" + configKey + ".cfg"));
} catch ( FileNotFoundException e ) {
return Collections.emptyList();
}
}
That's a simple, easily makable, and readable change. In fact, now I've got
the original version
still kicking around (in case I want it later), and I've got the translated
version -- which is
really semantically different than "configKey" in the previous version --
automatically being used.
I'm pretty sure that change meets all your criteria.
> The optimal way to solve this one in a functional view of the world is
> to first create a new variable (keyNormalized or something), and then
> UNDEFINE the old one. This way anyone that tries to use the original
> gets an error which should quickly lead to him or her coming up with
> the right solution (either use the normalized version or create a new
> paramRaw variable to make it abundantly clear what's happening).
> However, java doesn't support that.
>
I just did it. Now, I didn't undefine the old variable, but I also don't see
how undefining the
variable is a part of the "the optimal way to solve this one in a functional
view of the world".
Sure, it's common to build up structures like:
let foo = "f" in
let foo = foo + "o" in
let foo = foo + "o" in ...
But that's more a hack around immutability than part of the functional view of
the world. Insofar
as that code can be conceived of as functional, this would be just as
functional:
let f = "f" in
let fo = f + "o" in
let foo = fo + "o" in ...
>
> Hence, my theory is: In anything but the most trivial of examples,
> inlining the transformation as you did in your myConcat method, is a
> bad thing more often than it being a good thing. Yes, there was a typo
> in your code (double 'left'), but I found that utterly unconvincing,
> because this typo is exactly as likely in your 'correct' method:
>
> String myConcat(final String left, final String right) {
> if ( left == null ) return myConcat("", left);
> if ( right == null ) return myConcat(left, "");
> return left + right;
> }
>
We're now back into the academic, but since we're arguing what types of errors
are more likely, I'd
argue that an alarm bell is more likely to ring when you're putting a variable
named "left" into the
right side of an argument list as opposed to accidentally assigning the wrong
variable. So this
error case is less likely than the other.
Even if it's "just as likely", you're still not demonstrating the grievous harm
(or whatever) that
"final" apparently does.
~~ Robert Fischer.
Grails Training http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog
Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
