Why stunt the capabilities of getopt by shoehorning in other kinds of information in its switch strings?

In such cases, I usually just make a more complex structure which associates getopt switches to arrays which contain variables, help texts, validator functions and whatever else. Then I just map out the elements that Getopt::Long expects. For --help, I can also look at the switch strings and other clues to automate some of the messages for consistency.

This code is a sketch from memory. There are other structures that would do just as well.

my $Verbose;
my $Secret;
%Options = {
   'verbose+' => [ \$Verbose,
                   "Makes the output more verbose." ],
   'secret!' => [ \$Secret,
                  "Enables secret features." ],
};

...

sub usage {
  ...
  foreach my $option (sort keys %Options) {
    my $switch = $option;
    $switch =~ s/=.*$//;
    $switch =~ s/\W*$//;
    $message = $Options{$option}[1];
    $message .= " Adding $switch increases the effect."
      if $option =~ /\+$/;
    $message .= " Use --no$switch to disable."
      if $option =~ /\!$/;
    print Wrap(undef, undef, "$switch: $message"), $/;
}

...

GetOptions(map { $_, $Options{$_}[0] } keys %Options);
[download]

(One should mention the POD::Usage here, but I find it a little stiff, personally.)

--
[ e d @ h a l l e y . c c ]