Feature #11191
closedAdd #to_h method to OptionParser
Description
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.
Files
Updated by nobu (Nobuyoshi Nakada) over 9 years ago
- 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?
Updated by injekt (Lee Jarvis) over 9 years ago
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?
Updated by zzak (zzak _) over 9 years ago
I think having strings is better than nothing, but I do think symbols would be better.
You want symbols, I'm guessing for kwargs?
Updated by injekt (Lee Jarvis) over 9 years ago
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.
Updated by nobu (Nobuyoshi Nakada) over 9 years ago
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.
Updated by nobu (Nobuyoshi Nakada) almost 9 years ago
- 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]