No named parameters in Ruby?

14,159

Solution 1

What's actually happening:

# Assign a value of "meh" to scope, which is OUTSIDE meth and equivalent to
#   scope = "meth"
#   meth(1, scope)
meth(1, scope = "meh")

# Ruby takes the return value of assignment to scope, which is "meh"
# If you were to run `puts scope` at this point you would get "meh"
meth(1, "meh")

# id = 1, options = "meh", scope = "scope"
puts options

# => "meh"

There is no support* for named parameters (see below for 2.0 update). What you're seeing is just the result of assigning "meh" to scope being passed as the options value in meth. The value of that assignment, of course, is "meh".

There are several ways of doing it:

def meth(id, opts = {})
  # Method 1
  options = opts[:options] || "options"
  scope   = opts[:scope]   || "scope"

  # Method 2
  opts = { :options => "options", :scope => "scope" }.merge(opts)

  # Method 3, for setting instance variables
  opts.each do |key, value|
    instance_variable_set "@#{key}", value
    # or, if you have setter methods
    send "#{key}=", value
  end
  @options ||= "options"
  @scope   ||= "scope"
end

# Then you can call it with either of these:
meth 1, :scope => "meh"
meth 1, scope: "meh"

And so on. They're all workarounds, though, for the lack of named parameters.


Edit (February 15, 2013):

* Well, at least until the upcoming Ruby 2.0, which supports keyword arguments! As of this writing it's on release candidate 2, the last before the official release. Although you'll need to know the methods above to work with 1.8.7, 1.9.3, etc., those able to work with newer versions now have the following option:

def meth(id, options: "options", scope: "scope")
  puts options
end

meth 1, scope: "meh"
# => "options"

Solution 2

I think 2 things are happening here:

  1. You are defining a parameter on the method named 'scope' with a default value of "scope"
  2. When you call the method, you are assigning the value "meh" to a new local variable named 'scope', which is unrelated to the parameter name on the method you are calling.

Solution 3

Although named parameters are not supported by the Ruby language, you can simulate them by passing your function arguments through a hash. For example:

def meth(id, parameters = {})
  options = parameters["options"] || "options"
  scope = parameters["scope"] || "scope"

  puts options
end

Which can be used as follows:

meth(1, scope: "meh")

Your existing code simply assigns a varaible, then passes that variable to your function. For more information see: http://deepfall.blogspot.com/2008/08/named-parameters-in-ruby.html.

Share:
14,159
JohnMetta
Author by

JohnMetta

Scientist, programmer, and a digger of all things tech nestled snugly in the Columbia River Gorge (i.e. Heaven). When not paying my mortgage, I'm building Hydrasi, an environmental data company that is trying its best to drag the environmental sciences kicking and screaming into the 21st century.

Updated on June 07, 2022

Comments

  • JohnMetta
    JohnMetta about 2 years

    This is so simple that I can't believe it caught me.

    def meth(id, options = "options", scope = "scope")
      puts options
    end
    
    meth(1, scope = "meh")
    
    -> "meh"
    

    I tend to use hashes for argument options just because it was how the herd did it– and it is quite clean. I thought it was the standard. Today, after about 3 hours of bug hunting, I traced down an error to this gem I happen to be using that assumes named parameters will be honored. They are not.

    So, my question is this: Are named parameter officially not honored in Ruby (1.9.3), or is this a side effect of something I'm missing? If they are not, why not?

  • JohnMetta
    JohnMetta over 12 years
    Yup, that's what I was assuming was going on. I'd never thought about it because I'd never actually used named parameters in Ruby. I've always used a hash. Then when I saw it in this otherwise well coded gem, it surprised me.
  • brymck
    brymck over 12 years
    @JohnMetta Yeah, it sounds like a mental lapse on the part of the developer. It would probably be a good idea to let him or her know, but I can't blame the dev for wishful thinking. ;)
  • JohnMetta
    JohnMetta over 12 years
    I did do that. Github issue. I was considering rebuilding it and submitting a pull request, but I need to get motion on my project first, so will just have to work around it for now.