Keyword Arguments

So now that you've been able to read through Matz's keynote slides you'll notice he focused on "wild and crazy" ideas for Ruby 2.0 (in the current 1.9 branch). The one that seems to have hit the biggest nerve in the community is keyword arguments. The idea is to allow method calls to specify name-value pairs for the arguments so that at least some of the arguments can be placed out of order so long as you remember the argument names.

If you happen to use Rails you'll notice that the Rails team has shifted a number of the most often used methods such as find() and render() to accepting hashes with specific keys as method arguments. The idea is to approximate behavior more like that for any method, but to have the arguments still declared in the method declaration so that they'll be picked up in documentation without explicitly saying that the method expects a hash and to then list the keys and whether they're optional or required and what they represent.

You can check out the 3 suggestions that Matz presented in his slides. The worst of the bunch is option number 3, the rest/keys approach.

def baz(*rest, a:4, b:0, **keys)
  ...
end

baz()            # rest=[], a=4, b=0, keys={}
baz(1)           # rest=[1], a=4, b=0, keys={}
baz(a:1)         # rest=[{a:1}], a=1, b=0, keys={a:1}
baz(a:1, b:2)    # rest=[{a:1, b:2}], a=1, b=2, keys={a:1, b:2}
baz(1, 2, b:2)   # rest=[1,2,{b:2}], a=4, b=2, keys={b:2}
baz(c:2)         # rest=[{c:2}], a=4, b=0, keys={c:2}

Let's just say - ugh, no way, now how am I ever going to like that.

Option 2 changes the syntax of Ruby too much, it creates a need to make non-positional keyword-able arguments to include a trailing colon.

def bar(a:, b:0)
  ...
end

bar()          # error! a is mandatory
bar(1)         # error! no positional argument
bar(a:1)       # a=1,b=0
bar(a:1,b:2)   # a=1,b=2
bar(b:2)       # error! a is mandatory
bar(c:2)       # error! c is not defined

The caller shouldn't have to add the colon to make the "a" argument mandatory, we already know and have a syntax for that, nor does it seem like we'd ever want to explicitly disable positional arguments to allow keyword calls - and they shouldn't be mutually exclusive.

The first option is the least worst of the bunch:

def foo(a, b=0, c:4)
  ...
end

foo(1)          # a=1, b=0, c=4
foo(1,2)        # a=1, b=2, c=4
foo(1, c:2)     # a=1, b=0, c=2
foo(1, 2, c:3)  # a=1, b=2, c=3

With this option we're adding new syntax to make an argument able to be called as a keyword, similar to an optional argument. But here's the thing - why do we even need to make the argument as "keyword-able" in the method declaration? Why shouldn't any argument be able to be called as a keyword so long as when the method is called they keyword is specified as the argument name? Then we can keep our old syntax in method declarations, not break any existing code and move forward with keyword argument calls.

As you can see, I don't like any of the suggestions Matz presented at RubyConf 2005. Keyword arguments should be simple and intuitive without explicitly changing the method declaration syntax. For a proposal that I like which expounds on what I mentioned above, check out Daniel Berger's entry about keyword arguments. I vote an overwhelming yes for that proposal.

YARV 0.3.2 released, YARV OOPSLA 2005 slides

Yet another big (but very quiet) release of the VM that will be the base for Ruby 2.0. Sasada Koichi has quietly released YARV 0.3.2, back on 10/10. This release includes Native threading with pthread / win32 threads! It also includes support for Proc, Binding and eval, and a number of bug fixes. Now, I'm no expert on all this, and I don't have any idea of Ko1's plans - but from that feature list it would appear that we're getting awfully close to an official release of Ruby merged with YARV. He's already got YARV and Ruby merged in his trunk and has moved on to native threading. Might we see alpha/beta Ruby 2.0 candidates soon? Or maybe it's just wishful thinking?

For those who just can't get enough YARV, Sasada also has his draft slides up in PDF format for OOPSLA 2005. Be sure to take a look and give him some feedback.