Reinier Zwitserloot wrote: > Misses the point - with a single modification the code doesn't really > get any smellier, and you still don't have to look if the method > itself refers to the original variable or not. You still haven't > proved the harm in making a single modification up top, other than > losing the protection of final, which is indeed a shame and I'd love > some sort of keyword or style checker for it. I may write one > sometime. >
Why write a keyword style checker to gain "the protection of final" when you've got "final"? At this point, it seems like you're disagreeing to be disagreeable -- you've admitted that there's a protection of "final" which is good (and is a shame to lose), you've once claimed that there was great harm in using final but failed to demonstrate any real case of that (and have since abandoned the claim), and your one major counter-example has been shown to be a code smell that "final" neatly exposes. If you've changed your mind through the course of this conversation, that's cool. If not, I'm apparently missing something and I'd appreciate a refresher of the argument you're laying out. ~~ 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 Reinier Zwitserloot wrote: > Misses the point - with a single modification the code doesn't really > get any smellier, and you still don't have to look if the method > itself refers to the original variable or not. You still haven't > proved the harm in making a single modification up top, other than > losing the protection of final, which is indeed a shame and I'd love > some sort of keyword or style checker for it. I may write one > sometime. > > On Feb 16, 4:41 pm, "Robert Fischer, Smokejumper Consulting" > <[email protected]> wrote: >> On Feb 14, 11:22 pm, Reinier Zwitserloot <[email protected]> wrote: >> >>> And when we need to make another modification, we.... rename the >>> parameter to 'reallyOldConfigKey'? >> To deal with this case (configured once, and then configured again), >> you've got four options: >> 1) Remove final, which you should train yourself to be a sign you're >> probably doing something wrong. >> 2) Nest method calls ( translateNewerKeyNames(translateOldKeyNames >> (oldConfigKey)) ) >> 3) Add another intermediate variable (your "reallyOldConfigKey") >> 4) *Refactor the code* so you get one method. >> >> That pain you're seeing? That weird code smell of >> "reallyOldConfigKey"? That's the sign you should be refactoring so >> that your increasingly complex parameter mangling can get some unit >> tests wrapped around it. That sign is obvious when you're using >> "final", but easily obscured when you don't. These kinds of signs are >> exactly the reason I'm such a fan of 'final': it rapidly exposes bad >> coding practices and points when things should be refactored and >> cleaned up. >> >> ~~ Robert. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
