[Pdx-pm] RFC: Getopt::Modern

[Eric Wilhelm]

Maybe that's not the best name, but bear with me.  I've been working on 
Getopt::Helpful (which is another story) which has thus-far been a 
documentation+stuff front-end to Getopt::Long.

Today, I think I've lost both my mind and my patience.

Please respond with your answers to any or all of the following 
questions and/or comments on the below statements.

=====================================
Basis:  The below statements are assumed as facts about the way things 
are and/or should be.

Getopt::Long is 15 years old and has had to be continually
reverse-compatible.  This makes it far too lax in some respects and
unconfigurable or hard to use in others.  => time to rebuild.

Bundling should be limited to options which do not allow an argument
(e.g. -cvx, not -y24j15) unless the last one is the only one in the
bundle (in which case the value should not be part of the bundle (e.g.
-cvxy 24).)

Get rid of the --foo=this syntax.  We don't need it.

Complain if I spec two options with the same name
  Or at least let me set the behavior to drop/overwrite/die
  (e.g. 'v=i' and 'v|verbose')

Let me whittle the array down in separate pieces
  (pass-though option, etc.)

Long names start with "--", short names start with "-".  We stop at 
"--".
  That's it.  Stop the madness!  Options do not need to be able to 
  start with @%$#&*^/?<> or .

  The autoabbrev functionality is nice, but should not be allowed to
  descend into arguments which start with only one '-'.

Filling a config hash should use the longest option-name (not just the
first.)

Some way to parse options which aren't in @main::ARGV
  (e.g.  sub complicated {... $opt->ParseOptions(@_);...})

Do it in *my* order (because the user is clueless (and rightly so!))
  Options should be able to be given by the user in any order, but
  should be evaluated in the order that the programmer listed them (so
  that e.g.  '--option 8 --no-option' gives the same results as
  '--no-option --option 8' when $opts{'no-option'} = sub
  {@{$opts{option}} = ()};)


=====================================
Questions:

*  Is this a good name?  I realize that Modern is inherently dated 
(maybe I'll get lucky and it will just be Getopt in Perl 6.)

*  Has somebody already done it?  I've dug around on CPAN.  The above 
requirements are all AFAICT unmet.

*  Where else should I post this?  I don't want to cross-post, so I 
figured I would start at the local level.  Module-authors seems 
inappropriate, since modules don't parse command-line options.

*  Does anybody write command-line programs which nearly as many options 
as I do?

*  If yes to the above, then what is the preferred method of parsing the 
arguments?

*  Do the above requirements seem reasonable?  I'm trying to come up 
with something which works in a predictable way at the command-line, 
while still being flexible and configurable on the API side of things.  
This necessitates the use of a tender iron fist.	

*  Does this make any sense?  After all, I have lost my mind.

*  Are there other questions that I should be asking?

* Did you read this far?  Awesome!  Thanks.

--Eric
-- 
Don't worry about what anybody else is going to do. The best way to 
predict the future is to invent it. 
                                                 -- Alan Kay
---------------------------------------------
    http://scratchcomputing.com
---------------------------------------------