Feature #11191: Add #to_h method to OptionParser

• Status: Closed
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: -

[injekt (Lee Jarvis)]

Simply collecting configuration values is a very popular use for OptionParser. Code like this is quite common:

config = {}
opts = OptionParser.new do |o|
  o.on "-h", "--host=HOST", "hostname" do |h|
    config[:host] = h
  end
  o.on "-p", "--port=PORT", "port", Integer do |p|
    config[:port] = p
  end
  o.on "-v", "--verbose" do
    config[:verbose] = true
  end
  o.on "-q", "--quiet" do
    config[:quiet] = true
  end
end
opts.parse!
# do something with config values

This boilerplate is one of the reasons I built Slop: https://github.com/leejarvis/slop

I'd like to add a to_h method to OptionParser which returns a Hash containing the switch name and switch argument values. This would reduce the above example to:

opts = OptionParser.new do |o|
  o.on "-h", "--host=HOST", "hostname"
  o.on "-p", "--port=PORT", "port", Integer
  o.on "-v", "--verbose"
  o.on "-q", "--quiet"
end

With this example, the output would look something like:

opts.parse %w(--host localhost --port 8000 --verbose)
puts opts.to_h #=>
  {:host=>"localhost", :port=>8000, :verbose=>true, :quiet=>nil}

I've attached a patch that implements this functionality in quite a basic way. I'm very keen to hear what others think.

[nobu (Nobuyoshi Nakada)]

• Description updated (diff)
• Status changed from Open to Feedback
• Assignee set to nobu (Nobuyoshi Nakada)

Very interesting idea.

This is not acceptable as-is though, because of the design that an OptionParser instance should not be modified (and may be frozen) at parsing.

Currently, you can get a hash by using parse_in_order directly, the keys will be strings however.

config = {}
opts.__send__(:parse_in_order, %w(--host localhost --port 8000 --verbose), config.method(:[]=))
p config #=> {"host"=>"localhost", "port"=>8000, "verbose"=>true}

What you want is a method like this?

[injekt (Lee Jarvis)]

This is not acceptable as-is though, because of the design that an OptionParser instance should not be modified (and may be frozen) at parsing.

Yes good point.

Currently, you can get a hash by using parse_in_order directly

I noticed that too. This functionality is not exposed though, and I think it should be.

the keys will be strings however

I think having strings is better than nothing, but I do think symbols would be better.

What you want is a method like this?

Yes exactly. This will remove much of the boilerplate I mentioned above. However, the functionality should be exposed (I'm not sure if your code was suggesting that this is a documentable feature or just a workaround). This is made a little more difficult with the design that an OptionParser instance should not be modified at parse time. Do you have any other ideas for a workaround?

[zzak (zzak _)]

I think having strings is better than nothing, but I do think symbols would be better.

You want symbols, I'm guessing for kwargs?

[injekt (Lee Jarvis)]

You want symbols, I'm guessing for kwargs?

Sure, but not necessarily just for that. It's very common to see these config hashes contain symbol keys, so no reason to not provide them as such.

[nobu (Nobuyoshi Nakada)]

Lee Jarvis wrote:

Yes exactly. This will remove much of the boilerplate I mentioned above. However, the functionality should be exposed (I'm not sure if your code was suggesting that this is a documentable feature or just a workaround). This is made a little more difficult with the design that an OptionParser instance should not be modified at parse time. Do you have any other ideas for a workaround?

An idea is to add a keyword argument to OptionParser#parse and so on.

[nobu (Nobuyoshi Nakada)]

https://github.com/nobu/ruby/tree/feature/11191-optparse-into

[nobu (Nobuyoshi Nakada)]

• Status changed from Feedback to Closed

Applied in changeset r53444.

---

optparse.rb: into kwdarg

• lib/optparse.rb (OptionParser#order!): add into optional
  keyword argument to store the results. [Feature #11191]