From: Jim Freeze Date: 2005-07-04T12:16:19+09:00 Subject: Re: [ANN] Application-0.6.0 * Levin Alexander [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. > Jim Freeze wrote: > > > 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 > # # > # -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