> [Quoting Eric Wilhelm, on June 16 2005, 15:14, in "Re: RFC:
> Getopt::Mo"]
> > 15 years * n requests/year = 15*n degrees of flexibility =
> unpredictable
>
> Hmm. I'd say
>
> 15 years * n requests/year * m happy users = reliability
>
> which is as meaningless as your formula.
Its not just happyness with the reliability, its also the reliability of the author. I know for a fact that Johan responds to patches and bug fixes and feature requests quickly, and usually in a way that makes the user happy. (I think he turned down one patch of mine, but applied at least two or three so im happy with those odds.) OTOH, and no offence Eric, I don't know about you and your responsiveness. ID say its pretty hard to beat Johans.
>
> > True, but Getoptions() currently contains all of the "expertness" of
> > G::L, which means that other modules cannot learn anything about the
> > options (such as when Getopt::Helpful would like to know if these are
> > simple/float/list/hash, etc options without re-implementing G::L's
> > parsing.)
>
> I can make this information available, if users would be interested.
Well, you already published the rules for parsing the options which was all I needed to write a wrapper around G::L to have it integrate INI file configuration and an a simplified interface for implementing defaults and options in a single hash.
>
> > If you tear it apart and put it back together in pieces,
>
> How I do it, is my responsibility.
Agreed. So long as the parse rules don't change bizarrely IMO publishing them should be sufficient.
> > >* multi-pass support
> > > I think this is possibly the only real improvement to G::L.
> >
> > And, (from my reading of G::L) one that requires a fundamental
> > restructuring of the code.
Unless I misunderstand what you mean by multipass here I think you are wrong:
{
local @[EMAIL PROTECTED];
Getoptions(....);
}
Getoptions(....);
Done. And that's exactly what I do in Getopt::Long::INI (which thanks to this thread I now remember I need to upload to CPAN.)
> I currently have two projects that address this issue: Getopt::Toolkit
> (which is based on Getopt::Long) and Getopt::Long version 3 (which is
> a complete redesign, a.k.a. Getopt::Long on steroids). Merging the two
> projects into a single new Getopt::Long version is somewhere on my
> TODO list. HOWEVER, since I highly appreciate my happy users, whatever
> comes out of the merge will be drop-in compatible with the current
> Getopt::Long. If this implies that you will not use it because it is
> too flexible, that's fine with me. One unhappy user against a zillion
> happy users.
OOOH. Maybe I shouldn't upload Getopt::Long::INI after all...
Anychance of some previews?
>
> Finally, I must say, your web site makes me sad.
I can see why. Just so you know many of us hold G::L and yourself in high regard.
Cheers,
Yves
