Well, Obviously it's somewhat slower to load:
$ time perl -MGetopt::Std -e 1 0.07user 0.00system 0:00.07elapsed 97%CPU $ time perl -MGetopt::Long -e 1 0.19user 0.05system 0:00.23elapsed 102%CPU $ time perl -MGetopt::Declare -e 1 0.59user 0.08system 0:00.67elapsed 99%CPU
For the option parsing itself, that'll depend on how much extra work you put into the declaration (action blocks, more sophisticated parameter checking, etc.). Certainly it isn't the option-processing answer to every problem, but if it's easy to code and read and the startup/parse hit (amortized over runtime) isn't crucial, it is certainly worth looking into. It won't compete with Getopt::Std for efficiency on simple things, but there's a boatload of functionality I didn't mention -- here's the clustering example from the docs:
For example, given the parameter specifications: -+ Swap signs -a Append mode -b Bitwise compare -c <FILE> Create new file +del Delete old file +e <NICE:i> Execute (at specified nice level) when com +plete The following command-lines (amongst others) are all exactly equivalen +t: -a -b -c newfile +e20 +del -abc newfile +dele20 -abcnewfile+dele20 -abcnewfile +e 20del
Also: optional parameter lists, abbreviations, mutex directive (only one of a given set of options may appear on the command line). And, it can be told to parse a config file rather than @ARGV, and can return the parser object itself so you could use it to parse multiple such sources. There might even be a kitchen sink in the source somewhere, and you never know when one of those will come in handy.
In reply to Re: Re (tilly) 1: Getopt::Declare
by danger
in thread Getopt::Declare
by danger
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |