Heh. Bug in my code. Good news is that compiler would have caught it for me.
Score one for static
typing.
The line should be:
final String configKey = translateOldKeyNames(oldConfigKey); //V2.1
~~ Robert.
Robert Fischer wrote:
> 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
>
--
~~ 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
-~----------~----~----~----~------~----~------~--~---
