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<[email protected]> > 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. > > > > > > > > > > > >
