This post originated from an RSS feed registered with Ruby Buzz
by Daniel Berger.
Original Post: The Price of Explicitness
Feed Title: Testing 1,2,3...
Feed URL: http://djberg96.livejournal.com/data/rss
Feed Description: A blog on Ruby and other stuff.
In the continuing saga over the Rite vs Sydney style of keyword arguments, David Black makes a salient point:
I don't want my choice of local variable names to be coupled to calling code. If I offer keywords or hash keys, that means I've decided that I *do* want to publish those names, and commit to them. Otherwise I consider them strictly the method's business, not the caller's.
I understand his hesitation, but let's step back for a moment and look at a larger issue.
The core library has about 50 classes, and each of those classes has several methods. There are more in the standard library. If we adopt Matz's approach to keyword arguments, we'll immediately have to make a choice:
1) We will provide keyword arguments for the core and/or stdlib methods. 2) We will not provide keyword arguments for the core and/or stdlib methods.
If we choose option 2, then I don't see any compelling reason to add keyword argument support at all. We can all just resort to the "yield self if block_given?" trick, or hash parsing, like we've always done. So, let's say we choose option 1 - we want to provide keyword arguments for the core and/or stdlib methods. Now let me ask you the million dollar questions:
* Which methods? * What arguments will we add keyword support for?
I can already predict how this is going to go:
Person-1: I think we should allow keyword arguments to Array#new. Person-2: Why? There are only two parameters and they're both optional. Person-1: Because I want to be able to be more clear in my code, e.g. Array.new(size: 10, obj: "A") Person-3: Hmm..that doesn't sound bad, but we need to change "obj" to something more meaningful. Person-1: Like what? Person-3: How about something like "default"? Person-1: Hey, Person-2, you forgot about the second form where it takes an array! Person-3: Oh, then maybe we should allow an "array" keyword argument. Person-2: But what happens if the programmer does something like this: Array.new(size: 10, array: [1,2,3])? Person-1: Hm..we'll have to give priority to one of the keyword arguments then. Person-2: I dunno if I like "default" Person-3. How about "value" instead?
AD NAUSEUM.
And I have little doubt that a similar conversation will happen for every....single....method of every...single...class. In the end, we'll resort to one of two things - we'll provide keywords argument support for all parameters, or none of them, because no one will be able to agree on just which arguments should allow keyword support.
Ok, so what about 3rd party libs? You want control over your keyword declarations, so you put out your wonderful "foo" library, and it looks something like this:
class Foo
def bar(name, age, gender: "male")
...
end
end
If you do this, you had better prepare yourself from the inevitable onslaught of questions that will follow:
"Why can't I use 'name' and 'age' as keywords?" "Can we just add 'age' and not 'name'?" "Why did 'gender' get a default value and not the other ones?"
Some authors will bend to their users requests, and then that separation of implementation and interface they're so proud of goes up in smoke as slowly, but surely, they say "fuck it" and give *all* of their parameters keyword support. At least with Sydney I can just tell the end users to buzz off and use the positional parameters instead if they don't like it.
I could be wrong. Perhaps I'm being paraonoid and none of this will come to pass. Perhaps we'll come to a reasonable consensus with regards to the core and standard library.
Previous Topic
