Front page | perl.perl5.porters |
Postings from April 2003
Re: [PATCH 5.8.1 @19053] Getopt::Std
Thread Previous
|
Thread Next
From:
Johan Vromans
Date:
April 3, 2003 01:44
Subject:
Re: [PATCH 5.8.1 @19053] Getopt::Std
Message ID:
16012.609.495630.684285@phoenix.squirrel.nl
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
Getopt::Long)?
> +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.
> If C<HELP_MESSAGE()> or C<VERSION_MESSAGE()> are
> +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
APIs...
-- Johan
Thread Previous
|
Thread Next