Tag: named parameters. method calls

In an earlier article, Default and Named Parameters in C# 4.0 / Sith Lord in Training, I wrote about how C# 4.0 – that’s the version coming out with the next release of Visual Studio, known as Visual Studio 2010 – is going to provide support for named parameters.

In that article, I also incorrectly stated that Ruby supported named parameters. Luckily, Jörg W Mittag spotted my mistake an corrected me in a comment. I’ve since corrected the article and thought I’d show you how I got it wrong in the first place.

Ruby and My Named Parameter Goof

I had a vague recollection of Ruby accepting named parameters. I figured I’d be empirical and fired up irb – the Ruby REPL shell – and put together a quick little method to see if the recollection was correct:

# Ruby 1.8.6
def test_named_params(first, second)
    puts "#{first}\n#{second}"
end

Once put together, I made some test calls to the method:

# irb session (Ruby 1.8.6)
irb(main):> test_named_params("alpha", "beta")
alpha
beta
=> nil

irb(main):> test_named_params(first = "alpha", second = "beta")
alpha
beta
=> nil

Seeing that the interpreter didn’t choke on that named parameter call, I thought to myself “Vague recollection confirmed, Ruby supports named parameters!” and wrote the blog article.

Had my brain actually been firing on all cylinders, I would’ve given the method a proper test by providing the named parameters out of the order in which they appear in the method signature. Here’s what I would’ve seen:

# irb session (Ruby 1.8.6)
irb(main):> test_named_params(second = "alpha", first = "beta")
alpha
beta
=> nil

Uh-oh. If named parameters worked, the first output line would be “beta” and the second would be “alpha”. Clearly something’s wrong with my recollection.

Let’s try some non-existent named parameters – say, ones involving current entertainemtn news headlines — just to see what happens:

# irb session (Ruby 1.8.6)
irb(main):> test_named_params(lindsay_lohan_dui = "alpha",
jim_cramer_smackdown = "beta")
alpha
beta
=> nil

Even with nonsensical named parameters, the method is still accepting the values in order. Why is that?

Just about everything in Ruby has a return value (which can be anything, including nil). You can see for yourself in irb – here’s a quick do-nothing method definition:

irb(main)> def doNothing
irb(main)> end
=> nil

As you can see. defining a method returns a value of nil.

As Jorg pointed out, Ruby assignment statements return a value: the value used in the assigment. Once again, for proof, I’ll use an example from an irb session. In the example below, assigning the string "alpha" to the variable first also returns the string "alpha":

# irb session (Ruby 1.8.6)
irb(main):> first = "alpha"
=> "alpha"

In the call to test_named_params, the Ruby interpreter was interpreting my “named parameters” as assignment statements. first = "alpha" evaluates to plain old "alpha", but so does second = "alpha" (and for that matter, so does lindsay_lohan_dui = "alpha"). Each assignment statement in my parameter list was evaluated, and then those values were passed to method in positional order.

Python Supports Named Parameters

After getting the comment from Jorg and correcting my article, I wondered why I thought Ruby supported named parameters. Then it hit me – it’s Python.

So I fired up the Python REPL and put together this quick little method:

# Python 3.0
def test_named_params(first, second):
    print("%s\n%s" % (first, second))

And this time, I decided to be a little more thorough in my testing:

# Python 3.0 REPL
>>> test_named_params("alpha", "beta")
alpha
beta

>>> test_named_params(first = "alpha", second = "beta")
alpha
beta

>>> test_named_params(second = "alpha", first = "beta")
beta
alpha

And some additional searching on the web confirmed that yes, Python method calling does in fact support named parameters.

So in conclusion, when it comes to named parameters, it’s Python si, Ruby no…and C# pronto.