 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / Perl / Modules / July 2009Getopt::Auto improvements
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. 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 > I'd appreciate some advice here. > [quoted text clipped - 16 lines] > > Thanks. Good point. However I need to handle =head2 foo - .... (no option arg) versus =head2 foo (number) - .... (option arg) or, perhaps =head2 foo 3 - .... (3 args, passed to main::foo(1, 2, 3) I neglected to mention that the option foo implies a call to main::foo when the option is discovered. The specifier would indeed be completely optional, 'foo - ...' implying that main::foo takes no args. My basic question is this: What is the least intrusive way of indicating that there are a fixed number of args (variable number need not apply!) such that the user reading the man page generated from the POD that uses Getopt::Auto is not puzzled by the extraneous word(s) in the section header. > 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 [quoted text clipped - 51 lines] > > > > Thanks. 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. > 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 [quoted text clipped - 51 lines] > > > > Thanks. > 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? you might be interested to look at how getopt::euclid does it. it uses =for Euclid instructions aren't those modules kind of equivalent in fact? what are the advantages and drawbacks for each of them? jérôme  Signaturejquelin@gmail.com > > So that needs to be specified, and while 'foo - ....' is probably > > acceptable to the POD writer, 'foo int - ...' might be less so, [quoted text clipped - 11 lines] > advantages > and drawbacks for each of them? Jérôme, thanks. The key difference between Auto and Euclid is that Simon wanted to subject the POD writer to minimal inconvienence. I should have mentioned that option processing results in a call to main::foo, which would permit the user to do whatever checking was needed. # from Geoffrey Leach # on Monday 29 June 2009 12:34: >The key difference between Auto and Euclid is that Simon wanted to >subject the POD writer to minimal inconvienence. I should have >mentioned that option processing results in a call to main::foo, which >would permit the user to do whatever checking was needed. I have not looked at Getopt::Auto lately, but my Getopt::AsDocumented does some of what you're wanting to accomplish. I would say that Getopt::Auto could be implemented on top of AsDocumented (the main difference would be the calling of main::foo(), but also the options object), but I won't guarantee compatibility between Getopt::Base and Getopt::Long (and have no plans to do so.) My approach to what the pod contains was based on showing the user the information, so just: =item --foo FOO (number) Getopt::Base has been designed to do some mild validation, but does not actually do it yet (everything is a string at the moment.) See also Getopt::Abridged, which is like a gateway drug to Getopt::AsDocumented. --Eric Signature[...proprietary software is better than gpl because...] "There is value in having somebody you can write checks to, and they fix bugs." --Mike McNamara (president of a commercial software company) --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- Quoth geoff@hughes.net (Geoffrey Leach): > I'd appreciate some advice here. > [quoted text clipped - 12 lines] > 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. Something like =item foo (number) - ... might be OK. As Jonathan said, this must be strictly optional, of course. Ben |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2010 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.