# The following was supposedly scribed by
# Johan Vromans
# on Thursday 16 June 2005 02:21 am:
>[Quoting Eric Wilhelm, on June 15 2005, 16:58, in "RFC:
> Getopt::Modern"]
>As the author and maintainer of Getopt::Long I would be very
>interested to know what exactly your problems are.
I would love for Getopt::Long to be able to behave according to this
design, but I don't believe that it's feasible (unless it gets done
with BEGIN...require($one_or_the_other). In other words, I set out to
redesign both the architecture and the specification. If you're
interested in refactoring Getopt::Long, I would be happy to help.
"What design?" -> (roughly) trunk/data/notes/why_rebuild_getopt-long.txt
>Some points from your slides:
>
> G::L is actively maintained, which I think is more important.
And I commend you for it. I do often try to contact the author before
starting such patch/rewrite work and usually don't get an answer. In
this case, the rewrite was bound to be an independent exercise even if
the end result is ultimately a patch (which it most-likely can't be.)
>* 15 years old
> What do you mean by that? Perl is 18 years old. C is even older.
<re-arranging slightly>
>* too flexible
> Interesting point. I think G::L follows Perl in TIMTOWTDI.
> Most flexibility has been added on user request.
These two things go together to yield the third here. Sorry if that
wasn't clear.
15 years * n requests/year = 15*n degrees of flexibility = unpredictable
>* lacks predictable behaviour
> I fail to see your point here. Options are handled from left to
> right, which makes perfect sense.
To the computer, not the user. Please see below.
>* wants to deal with an API
> This is provided by the OO API of G::L.
> Besides, a single function is also an API.
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.)
If you tear it apart and put it back together in pieces, it would have
the API of which I speak.
>* not super-configurable
> Wow! Ain't this begging for a simple 2-line wrapper module around
> G:L instead of re-inventing the wheel?
No. If it involves typing @main::ARGV, something is wrong.
>* Arguments in bundles never looked right anyway
> I think this is where the personal / religious feelings kick in.
Could be. Is this something that can/should be resolved with
yet-another-option?
>* users do not (and should not have to) understand the programmer's
> problems
> I fail to see your point. Can you elaborate?
Please see the 'data/notes/why_order_matters.txt' in the repository.
>* 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.
>Personally, I doubt wheter this validates yet another Getopt:: module
>(unless you have fun writing it, which is important as well!)
I would love to just make this be Getopt::Long, but I rather doubt that
it would be possible (or maybe even desirable) for it to be
reverse-compatible with 15 years worth of code (except in the
(we're-really-just-faking-it) case of the aforementioned BEGIN hack.)
--Eric
--
Peer's Law: The solution to the problem changes the problem.
---------------------------------------------
http://scratchcomputing.com
---------------------------------------------
