Don't write a "framework" to do it. Don't write an overly-pedantic DSL.
Don't write a complicated OO system where for some INSANE reason you
decide that inheritance NATURALLY should be a critical component of
parsing the commandline.
That kind of behavior is NOT acceptable.
If I have to write more than one line of code per option, you're doing
it wrong. If I have to think about it, you're doing it wrong. If I have
to SUBCLASS something, for crying out loud, you're doing it VERY wrong.
But don't worry about it. Don't fret. I've already done it right, just
for you. With Trollop.
I have been perfecting Trollop for over three years. OVER THREE YEARS.
That probably makes it the longest-lived project in all Ruby history.
Trollop is not just epic. It is EPOCH. It is ART. It is PURE. And it is
1.9-compatible.
Seriously, people. What is it about option parsing that makes you go
crazy like this?
I have been perfecting Trollop for over three years. OVER THREE YEARS.
That probably makes it the longest-lived project in all Ruby history.
Trollop is not just epic. It is EPOCH. It is ART. It is PURE. And it is
1.9-compatible.
would it be nice if you could include arguments(ARGV) and then infer
the usage, so
1 it would be included in -h display
2 i wouldn't have to create a separate banner for it
?
simple illustration: what if i need at least two args for the command
mycopy source dest [dest2, dest3,...]
then mycopy -h should show at least
syntax: mycopy source dest [dest,..]
options:.....
i haven't lookuped the api though.
overall, trollop is quite nifty/speedy.
thanks and best regards -botp
···
On Tue, May 11, 2010 at 11:39 PM, William Morgan <wmorgan-ruby-talk@masanjin.net> wrote:
Reformatted excerpts from Michael Fellinger's message of 2010-05-11:
I have no idea what caused this rage of you,
Suboptimal software.
but would you kindly tell me what's wrong with OptionParser
(optparse.rb in stdlib)?
1. Too many positional arguments. Which is the correct version?
opts.on( '-f', '--float NUM', Float, "Convert to float" )
opts.on( '-f', '--float NUM', "Convert to float", Float )
If you have to look it up, optparse fails.
2. The use of blocks. 99% of the time you're just throwing stuff in a
hash anyways, in which case you now have to maintain the mapping between
hash keys and arguments. The rest of the time you're doing complicated
stuff in the blocks, in which case you have code mixed in the middle of
your argument list.
3. No notion of default arguments. You have to explicitly write them
into your code, e.g. by using a hash and initializing it.
4. If optparse knows your argument is named '--float', why doesn't it
automatically generate a short option '-f'? (Likewise, if optparse knew
what your default value was, it could infer the type-checking for you.)
5. Complicated API. on_head, on_tail, make_switch, etc.
6. I like for my help pages to be wrapped nicely, e.g.
Options:
--delete, -d: Delete everything
--restore, -r: Restore everything. Of course this doesn't actually
work. What's gone is gone. But it might make the user
feel hopeful for a second, and, after all, isn't that
valuable in and of itself? (default: true)
--help, -h: Show this message
Reformatted excerpts from Michael Fellinger's message of 2010-05-11:
I have no idea what caused this rage of you,
Suboptimal software.
but would you kindly tell me what's wrong with OptionParser
(optparse.rb in stdlib)?
1. Too many positional arguments. Which is the correct version?
opts.on( '-f', '--float NUM', Float, "Convert to float" )
opts.on( '-f', '--float NUM', "Convert to float", Float )
If you have to look it up, optparse fails.
The first one on first glance, but I'm using that library for years now.
2. The use of blocks. 99% of the time you're just throwing stuff in a
hash anyways, in which case you now have to maintain the mapping between
hash keys and arguments. The rest of the time you're doing complicated
stuff in the blocks, in which case you have code mixed in the middle of
your argument list.
The first one is true, it used to be nicer in 1.8 when people abused
the block pipes
You can put longer code into methods and use them as blocks:
o.on('-h', '--help', 'read me', &method(:help))
See ver/bin/ver at master · manveru/ver · GitHub as an example.
3. No notion of default arguments. You have to explicitly write them
into your code, e.g. by using a hash and initializing it.
You have to put your defaults somewhere, might as well be a Hash.
4. If optparse knows your argument is named '--float', why doesn't it
automatically generate a short option '-f'? (Likewise, if optparse knew
what your default value was, it could infer the type-checking for you.)
Because you'd rather not provide a short version for some stuff,
especially if there are two options called --float-min and
--float-max?
Again, a default value doesn't need to have anything to do with the
accepted values.
5. Complicated API. on_head, on_tail, make_switch, etc.
The API is actually very powerful, it takes a little effort to learn,
but you can go very far with it.
For example, I've implemented the ramaze binary using optparse so i
can actually handle subcommands without code duplication:
6. I like for my help pages to be wrapped nicely, e.g.
Options:
--delete, -d: Delete everything
--restore, -r: Restore everything. Of course this doesn't actually
work. What's gone is gone. But it might make the user
feel hopeful for a second, and, after all, isn't that
valuable in and of itself? (default: true)
--help, -h: Show this message
Not that I ever cared about that, I don't even understand what you
mean with big blob,
just pointing out it might be possible to get your preferred formatting too
That's all I can think of now...
Thanks.
···
On Wed, May 12, 2010 at 11:44 AM, William Morgan <wmorgan-ruby-talk@masanjin.net> wrote:
