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