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

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