Michael Wallner [2004-04-21 14:37 UTC] Definitely cool at a quick glance.
Tobias Schlitt [2004-04-21 16:20 UTC] I like the idea of this package very much. Looks cool.
But I wonder, if this couldn't be merged into current Console::GetOpt (or similar) to avoid redundancy?
Alexander Wirtz [2004-04-21 16:48 UTC] Great idea, I'm not very fond of the GetOpt package, imho it leaves much to be desired. As the python and perl packages are unknown to me, I'd like to know if it's possible to formulate "either-or" arguments. Even if this is not possible, I support the idea of an improved getarg-class very much...
Bertrand Mansion [2004-04-21 16:52 UTC] I thought about merging it with Console_Getopt but both packages have a different approach and accept different type of parameters. Furthermore, Console_Getopt is mostly a suite of static methods.
On the other hand, Console_Getargs or whatever the final name is, if it is accepted, uses a factory. So it should be easy to use the factory method to build a Console_Getopt object, althrough I am not yet sure how useful this would be.
If that's a requirement, I can investigate this issue further. It shouldn't add too much overhead, but the help generator will need a few more efforts to be adapted and won't provide descriptions.
If someone is interested in contributing the code that will make the factory build a Console_Getopt object (if this is actually possible), I am interested, as I am busy at the moment. ;)
Jan Schneider [2004-04-21 17:09 UTC] Really nice package.
Alan Knowles [2004-04-22 00:56 UTC] looks really nice - couple of things
it would be nice if the options array could accept a more verbose format.
file => array(
'shortopt' => 'f'
'minargs' => 1,
'desc' => 'this is the file..'
'required' => true
);
one of the other big problems with console getopt, is that I have to look up in the manual every time I see code using it.. (Even code I wrote myself a year ago..)
.. you may want to reduce the
if () {
if () {
if () {
if () {
- quite a few of these return from the conditions, so you dont need else.. on them.
Alexey Borzov [2004-04-22 11:03 UTC] Looks cool, but I completely agree with Alan that config array should really be associative. Having a long list of parameters is not good, I can't remember the semantics of parameters for some of QuickForm's methods...
Bertrand Mansion [2004-04-22 12:44 UTC] I have removed the useless if/else and fixed a bug in default-if-set feature.
I haven't uploaded the new sources yet as I will follow your comments and change the config to an associative array.
I am trying to figure out how to validate the values. Alan, you added a 'required' key to the config array. Others might want 'enum', where the user could only choose a value in a list or even 'either-or', where if one arg is used, another one can't be used, or minlength/maxlength, regex, ... looks familiar ;)
It looks like a larger Rule package could handle that better.
Still, I think it is important to keep min/max in the Console_Getargs package as, even if they can help the validation, it is also used for the arguments parsing.
Bertrand Mansion [2004-04-23 21:49 UTC] I have updated the source with support for an associative array. Have also updated the example and fixed a few bugs.
Greg Beaver [2004-04-29 03:12 UTC] What would be really cool is if there was also an HTML_Getargs to go along with Console_Getargs that had the same API. This way, both the CLI and Web frontends of PEAR could rely upon a getargs object to be passed in that would instantly support new command-line stuff.
If this were to happen, I would prefer the package name be Getargs_Console to allow Getargs_HTML or future developments (Getargs_Mindreading would be nice) :)
Greg
|
