About this mini-article series. Each day for 24 days, I will be reviewing a module that parses command-line options (such module is usually under the Getopt::* namespace). First article is here.

Getopt::Std::Strict is a module written by Leo Charre (LEOCHARRE) in 2008. The author is using this module in several of his CPAN distributions, but no one else on CPAN seems to be using it. More "recent" option parsing modules, such as those written after the mid-2000's, even including Docopt (port of a popular Python library) do not see much adoption on CPAN. This could be caused by various factors, the speculation of which I don't intend to get into right now. But I can say that there are two exceptions: Getopt::Lucid and Getopt::Long::Descriptive, and this might have something to do with the reputation of their authors.

Back to our module of the day. There are not a lot of wrappers for or "forks" of Getopt::Std, simply due to the fact that the module is so simple already. But the author of Getopt::Std::Strict has an itch to scratch. First, when we are in strict mode, instead of this:

getopts('oif:');

or:

getopts('oif:', \%opts);

one has to do this instead:

use vars qw($opt_o $opt_i $opt_f); getopts('oif:');

or:

my %opts; getopts('oif:', \%opts);

which the author probably finds annoying. So he wrote a module to declare the variable(s) for you. And to do this, the option specification needs to be passed/processed at compile time. Thus:

use Getopt::Std::Strict 'oif:', 'opt'; # will declare the $opt_* for you if ($opt_o) { ... } # so $opt_o can be used without you declaring it

This is rather nice because if you mistype $opt_o to $opt_p (an unknown option), this mistake will be caught at compile-time.

As a bonus, the module also provides you %OPT and opt() function. You can access for example the -o option via $OPT{o} , or via opt('o') . The former won't catch a typo e.g. when you type $OPT{p} but the later will ( opt('p')

will die).

I personally find all this rather unnecessary: I probably would just bear the cost of typing my %opts; or my ($opt_o, $opt_i, $opt_f); and be more explicit.

But I have a couple of suggestions. First, it might be nice if the module dies when user specifies unknown option (to be more inline with the "Strict" spirit in the name). And second, the bonuses are additional cognitive burdens that I'd personally do without. Or, if they are to stay, to be more strict the %OPT can be made to die too when fed unknown options too, e.g. using tie mechanism.