Front page | perl.module-authors |
Postings from July 2009
Re: Getopt::Auto improvements
Thread Previous
|
Thread Next
From:
Geoffrey Leach
Date:
July 15, 2009 10:05
Subject:
Re: Getopt::Auto improvements
Message ID:
1247677485.7503.0@mtranch.mtranch.com
Jonathan, thanks for the great imput.
I'm still puzzling over the implementation, but as long as the
discussion is happening, how's about this ...
An option --foo is specified. This implies that main::foo() will be
called when the option is found on he command line. My proposal is
that foo() is called with one argument: a reference to
@ARGV with the remaining unprocessed items.
For example, if we have myprog -foo bar morestuff, foo() would see
[bar, morestuff]. If foo() is not interested in anything else on the
command line, it would just do its thing and return (the current
behavior). Otherwise, foo() is free to shift off as many items in the
list as it wishes. Processing of the command line then continues
normally, and the items consumed by foo() are gone.
Suppose that 'morestuff' is non-option input to the program. It would
then be the @ARGV that the program sees at startup.
A potential glitch in this is that option processing takes place in an
INIT block, which is earlier than happens with GetOpt, for example.
On 06/29/2009 10:45:31 AM, Jonathan Yu wrote:
> Generally I think the old wisdom is to just assume all input is some
> sort of string, and to perform any validation you need manually or
> using other utilities like Scalar::Util's looks_like_number method
> (which is core anyway).
>
> However, it might be convenient to have a way to verify that input is
> an integer, or floating point number, or what-have you. I'm all for
> adding a feature to do this, as long as it's strictly optional --
> that
> is, a new Getopt::Auto should not break old scripts that expect the
> old behaviour.
>
> One "problem" with simple type validation like this is that you're
> going to be unable to catch certain things using such a simple
> validation method, and it will probably be combined with other things
> anyway.
>
> For example, if you have an --option which can only have the values
> 1,
> 2, 3 -- then you can require the field to be an int, but you're still
> going to have to check that it matches one of the available numbers
> anyway. So in practice I think any moderately robust module will
> implement their own sanity checking.
>
> Cheers,
>
> Jonathan
>
> On Mon, Jun 29, 2009 at 1:39 PM, Geoffrey Leach<geoff@hughes.net>
> wrote:
> > I'd appreciate some advice here.
> >
> > Getopt::Auto was conceived by Simon Cozens. I've recently adopted
> it.
> >
> > The idea with Getopt::Auto is that it scans your POD looking for
> =heads
> > or =item that have the format: 'foo - what this does is bar', the
> > single word followed by a dash being the critical parts, and
> constructs
> > an option-recognition scheme for foo.
> >
> > All this is well and good, but it seems to me that there's a flaw,
> > which is that there's no way to say that foo takes a string, or
> int,
> or
> > ...
> >
> > So that needs to be specified, and while 'foo - ....' is probably
> > acceptable to the POD writer, 'foo int - ...' might be less so,
> taking
> > into account that all of that appears in your POD's paragraph
> headings.
> >
> > Or am I wrong? Perhaps there's a better way?
> >
> > Thanks.
> >
> >
> >
> >
> >
>
>
Thread Previous
|
Thread Next