# Ruby 1.8.6
def test_named_params(params)
puts "#{params[:first]}\n#{params[:second]}"
end

# irb session (Ruby 1.8.6)
irb(main):004:0> test_named_params(:first => 'alpha', :second => 'beta')
alpha
beta
=> nil
irb(main):005:0> test_named_params(:second => 'alpha', :first => 'beta')
beta
alpha
=> nil
irb(main):006:0> test_named_params(:first => 'beta', :second => 'alpha')
beta
alpha
=> nil


Note that Ruby converts the method parameters into a single hash. This approach is used a lot in Rails, for example to simplify the process of associating form parameters with model attributes.

Hint: http://www.google.com/codesearch?hl=en&lr=&q=memset\s*\(.%2B%2C.%2B%2C0&sbtn=Search ;)

@David: Drop by PyGTA tonight, and I’ll show you some of the Objective-C I’ve been writing…

Later,
Blake.

In OCaml if you have named parameters you can keep currying the function til you’re done filling out the parameters.

In perl named parameters are just
sub { my %params = @_; … } and everything is in the params hash (really common place in perl)

Surely you could just pass a hash in ruby

Very useful info – esp since I may do some Objective C programming soon. Useful link. Anyone want to chime in about other languages. Lisp? Mathematica?

So, to regurgitate the infamous geometric shapes example: in Python, you would have a class Rectangle, with a constructor that takes two keyword parameters, width and height and it wouldn’t matter in which order you pass the arguments. In Smalltalk, instead of the constructor, you would have a factory method called width:height: and trying to pass arguments the other way round would result in a No Method Exception, unless you also define a height:width: method.

• I suspect that they’re included in Python because one of its core philosophies is “Favour the explicit over the implicit.” Named parameters make the meaning of each parameter very explicit.
• They’re useful in cases where different cultures use different ordering, such as dates. There’s no wondering if the argument order is month-day-year or day-month-year.
• With methods that have a large number of optional arguments, they’re pretty handy. I’ve seen method calls that have had to be written like someMethod(5, "fudge", , , , , True, , , "x") when it would’ve been nicer to just have someMethod(iterations = 5, flavor = "fudge", dontWhizOnElectricFence = True, discountCode = "x")
• The Ruby way (and especially the Rails way) of using named parameters is to accept a hash as an argument. From the caller’s point of view, there isn’t that much difference between myMethod(flavor = "fudge", sprinkles = False) and myMethod :flavor => "fudge", :sprinkles = false.

$ find . -name “*.py” | xargs grep Paginator
./contrib/admin/views/main.py:from django.core.paginator import Paginator, InvalidPage
./contrib/admin/views/main.py: paginator = Paginator(self.query_set, self.list_per_page)
./contrib/comments/views/moderation.py:from django.core.paginator import Paginator, InvalidPage
./contrib/comments/views/moderation.py: paginator = Paginator(qs, 100)
./contrib/sitemaps/__init__.py: self._paginator = paginator.Paginator(self.items(), self.limit)
./core/paginator.py:class Paginator(object):
./views/generic/list_detail.py:from django.core.paginator import Paginator, InvalidPage
./views/generic/list_detail.py: paginator = Paginator(queryset, paginate_by, allow_empty_first_page=allow_empty)

You may also want to add in here Objective-C – iPhone programming – and Smalltalk, as if I remember correctly more or less all parameters are named. Javascript by convention uses passing in a dictionary to achieve a similar result. URL parameters to APIs are effectively RESTful named parameters.

You can use a dictionary to pass in named parameters in Python:

d = { “second” : “alpha”, “first” : “beta” }
test_named_params(**d)

Also see two blog posts, the anything goes pattern for specialized catchalls, and my bitching at MS for not using named parameters!

How would you make a _practical_ programming API to this without named parameters. Hmmm. How does Ruby do it? (really)