develooper Front page | perl.perl5.porters | Postings from April 2003

Re: [PATCH 5.8.1 @19053] Getopt::Std

Thread Previous | Thread Next
Johan Vromans
April 3, 2003 01:44
Re: [PATCH 5.8.1 @19053] Getopt::Std
Message ID:
Ilya Zakharevich <ilya@Math.Berkeley.EDU> writes:

> This patch updates getopts() to the world of today.

Nice idea! Mind if I have some questions/remarks about the
implementation details (also w.r.t. corresponding functionality in

> +If C<-> is not a recognized option letter, getopts() supports arguments
> +C<--help> and C<--version>.

For Getopt::Long that would mean: add a '--help' and '--version'
option if the program did not specify one itself.

> +defined in the package C<main>, they are called (with the switches string
> +and C<GetOpt::Std> version as arguments); if not, an attempt is made to
> +generate intelligent messages; for best results, define $main::VERSION.

I can imagine why the switches string is passed to HELP_MESSAGE, but
why is it passed to VERSION_MESSAGE?
Also, I think it is not necessary to pass the version to the callback
routine, since it is available as $Getopt::Std::VERSION anyway.
Instead, it would be better to pass the name of the package that does
the options parsing (e.g., 'Getopt::Std'). In particular w.r.t. your
proposal for --getopt-ui (not --getopt-gui!).

> +In presence of these arguments getopts() calls
> +C<exit($GetOpt::Std::EXIT_ON_HELP_VERSION)> if
> +$GetOpt::Std::EXIT_ON_HELP_VERSION is defined.

I would suggest separate values for $EXIT_ON_HELP and
$EXIT_ON_VERSION. Rationale: If we later invent a third callback FOO,
we prevent the strange case of --version and --help returning
EXIT_ON_HELP_VERSION, while --foo returns EXIT_ON_FOO. Or --foo has to
return EXIT_ON_HELP_VERSION as well, which is also confusing.

Also, I would prefer

  use constant EXIT_ON_HELP_VERSION => 681;

instead of 

  our $EXIT_ON_HELP_VERSION = 681;

> +One can print the messages of C<--help> and C<--version> by calling functions
> +help_mess() and version_mess() with the switches string as an argument.

See my comment about the arguments above.

> +$0 version $v calling Getopt::Std::getopts (version $VERSION),

$0 may be set to something else and no longer reflect the program
name. Intgentional? Acceptable?

> +sub help_mess ($;$) {

I've been thinking about a standard help_message for Getopt::Long
since Tue, Sep 11 1990, 15:00:12. I've not been able to get to a
message format that would be acceptable for everyone, so I decided to
leave this explicitly out of Getopt::Long and point users to the power
of POD::Usage.

However, if we can agree on a good, universal help message format I
may reconsider.

> 	["input|i=s", argname => 'PATCHFILE',
> 	  help => 'Read patch from PATCHFILE instead of stdin.'],

I think it is easy and unabiguous to deduce the argname from the help
text, E.g.:

   "input|i=s?Read patch from <PATCHFILE> instead of stdin.",

This would allow implementation within the current Getopt::Long API.

> c) There should be a way to request/suppress sorting of options on --help.

I would never sort the options.

>   --getopt-gui=Foo,Bar
>     If Getopt::Long finds this option, it should try to delegate work
>     to Getopt::Foo, if not present to Getopt::Bar, if not present,

Extremely powerful, but also extremely dangerous. For one,
Getopt::Foo, Getopt::Bar and so on would have to support identical

-- Johan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About