* Levin Alexander <levin@grundeis.net> [2005-06-30 18:39:32 +0900]:
Hi Levin.
Thanks for your comments and feedback.
BTW, I am back from two trips, so I should
be able to respond a little faster now.
> option :debug, :arity => [1,1]
That would be my favourite. What about:
option :example {
names %w(--example -e)
arity [1,1]
opt_description "Option Description"
}>>$ ./testapp.rb --debug 2 file1 file2
>>
>>@debug #=> "2"I just realized that this does not work. How can I access option
arguments from my Application? Maybe there should be a Hash, like:arg[:example] #=> "2"
arg[:foo] #=> ["bar", "baz"]
arg[:not_given] #=> nil
Once the commandline is parsed, the data is put in @option_data.
They are accessed like hashes and the value is the result of
opt_found or opt_not_found.
... "arg" is probably not the best name
>>@file1 #=> "file1"
>>@file2 #=> "file2"Btw, what is the difference between:
:opt_found => Proc.new {|a,b| puts a,b}
# works, prints
# #<CommandLine::Option:0xb7d724a0>
# -t
and:
:opt_found => lambda {|a,b| puts a,b}
# does not work, prints
# ERROR: wrong number of arguments (3 for 2)
Both work, but lambda is designed for this type of
anonymous procedure passing. If you use Proc.new,
then you have to do weird things like use 'next'
instead of 'return' within the block.
>Your little example also got me thinking that the arguments
>to the application should be like those to the options--they
>should be able to take arguments. Maybe something like:
>
> args :number { |arg| arg.to_f }
> args :file1 { |arg| raise if File.exists(arg) }Yes, that would be quite useful. You should also support:
args :arity_2 { |arg1, arg2| ... }
That's not a bad shorthand. Have you seen that type of thing
done elsewhere?
···
Jim Freeze <jim@freeze.org> wrote:
--
Jim Freeze