This post originated from an RSS feed registered with Ruby Buzz
by Daniel Berger.
Original Post: Mo' Better Keyword Arguments
Feed Title: Testing 1,2,3...
Feed URL: http://djberg96.livejournal.com/data/rss
Feed Description: A blog on Ruby and other stuff.
It seems I've been picked up over at RedHanded with regards to keyword arguments in the last post. In the comments Tsela (and Matz) make an interesting point:
When one uses keyword arguments, one is basically breaking the premise that implementation details are hidden. Suddenly implementation details (the names of the arguments) become part of the interface.
What's he's saying here is that, under the current Sydney rules, all those crappy argument names that people used in their code, such as the ever popular "arg1" and the like, will suddenly be publicly available as keyword parameters.
First, don't panic. C extensions won't support keyword arguments without extra work. Since all the core Ruby classes are C, we won't have to worry about the fact that cruddy variable names are sprinkled throughout the code base.
Second, keep in mind that positional parameters are still valid. If the library you're using has badly named parameters in their method definitions....don't use them. In fact, I recommend against using them because they'll likely be refactored.
Third, lib authors need to suck it up. Refactor existing code to use sensical parameter names. I mean, seriously, what's your excuse for not doing this in the first place?
There's another consideration. Let's say we adopt Matz's proposal and only those parameters that are explicitly marked as keywords become available to end programmers as keyword arguments. Then consider that it's highly unlikely that any of the core and/or stdlib libraries will be refactored. You'll end up with this great feature that no one can use out of the box because none of the core libraries support it. In the event that the core and stdlib libraries are refactored, well, if you're going to go back and refactor anyway....
I won't even mention the rdoc changes we'll need.
I mean, I get his point. But, I simply feel the good far outweighs the bad. In the worst case, a few knuckleheads might decide to use some bad parameter names as keywords. I see this as a very unlikely scenario, and that's only if we don't refactor the parameter names. That, and (gasp) we'll all have to be much better about our parameter naming conventions.
On a final note, I'll say that the spirit of Ruby has always been one of implicitness rather than explicitness. I'd hate to see that broken here.
Previous Topic
