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

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

Thread Previous | Thread Next
From:
Ilya Zakharevich
Date:
April 3, 2003 12:54
Subject:
Re: [PATCH 5.8.1 @19053] Getopt::Std
Message ID:
20030403205439.GA6109@math.berkeley.edu
On Thu, Apr 03, 2003 at 11:44:01AM +0200, Johan Vromans wrote:
> > +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.

I think so too..

> > 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?

For consistency only.

> Also, I think it is not necessary to pass the version to the callback
> routine, since it is available as $Getopt::Std::VERSION anyway.

IMO, it is cleaner to use arguments than the global data.

> 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!).

Good ideas too!

> > +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.

The only purpose of $EXIT_ON_HELP_VERSION is the backward
compatibility, so one cannot make an arbitrary script exit early by
providing --help option.  This proposal looks like hair splitting; on
the other hand, it is trivial to implement: just check the variables
when setting $exit, not at the end of parsing...

> Also, I would prefer
> 
>   use constant EXIT_ON_HELP_VERSION => 681;
> 
> instead of 
> 
>   our $EXIT_ON_HELP_VERSION = 681;

Do not think so.  The fact that `use constant' is not lexical is just
a feature of implementation.

> > +$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?

IIUC, $0 is as good as it gets.

> > 	["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.

Maybe.  Only make the delimiter less frequent; e.g., "from <<<PATCHFILE>>>".

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

> I would never sort the options.

My usages of getopts() have switches in random order.  So I do not
care if they are sorted.  And if order does not matter, it is better
to sort (especially if the list is long).  So I think sorting may have
its usages.

> >   --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...

But this is a users responsibility.  If the user chooses
--getopt-ui=Tree, then we may assume they know something about
Getopt::Tree.

Hmm, versioning needs to be done.  The script should be able to
communicate which minimal version of Getopt::Long API it needs
(probably, differently than in 'use' line, unless Getopt::Long can
catch this).  Then Getopt::Long may interrogate Getopt::Tree whether
it supports the API.

Hope this helps,
Ilya


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About