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 4, 2003 02:15
Subject:
Re: [PATCH 5.8.1 @19053] Getopt::Std
Message ID:
16013.23365.639445.709858@phoenix.squirrel.nl
Ilya Zakharevich <ilya@Math.Berkeley.EDU> writes:
> > I can imagine why the switches string is passed to HELP_MESSAGE, but
> > why is it passed to VERSION_MESSAGE?
>
> For consistency only.
I do not understand. HELP_MESSAGE and VERSION_MESSAGE are two
different routines, with a different purpose. Moreover, I think the
VERSION_MESSAGE routine is much more general, and could be called from
other (non-Getopt) modules as well (e.g., from Config modules).
But I do see a purpose for the opposite: passing the module/version to
HELP_MESSAGE so it can treat the help information accordingly.
I propose the following APIs:
sub VERSION_MESSAGE {
my ($module, $version) = @_;
# $module is the calling module, e.g. "Getopt::Std".
# $version is the module version as a string, e.g. "2.14".
...
}
sub HELP_MESSAGE {
my ($module, $version, @info) = @_;
# $module is the calling module, e.g. "Getopt::Std".
# $version is the module version as a string, e.g. "2.14".
# @info is module/version dependent information. For example,
# Getopt::Std would just pass the options string.
# Getopt::Long can pass a hierarchically structured array of
# options and documentation string.
...
}
> IMO, it is cleaner to use arguments than the global data.
Agreed, especially since I think VERSION_MESSAGE could be called from
other modules as well.
> 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.
I see. I withdraw this part of the comments.
But there's a backward compatibility problem anyway: current scripts
treat --help and --version as illegal options that now suddenly become
valid with the new versions of Getopt::Std and Getopt::Long.
For Getopt::Long, I could add some config options, e.g.
use Getopt::Long qw(:config auto_help auto_version);
But this would defeat much of the niceness of transparently adding
support for --help and --version.
Ideas?
> > "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>>>".
Good suggestion.
> But this is a users responsibility. If the user chooses
> --getopt-ui=Tree, then we may assume they know something about
> Getopt::Tree.
I don't think average users will use this. I think it is useful for
applications that execute in a particular framework (e.g., Tk) and
hence it would be controlled by the framework. An environment variable
would be a better way to control this.
> 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.
This needs definitely more thinking...
-- Johan
Thread Previous
|
Thread Next