664, 668 - Getopt::Long

[Ovid]

Having just got back from the pub with mates, this is possibly the
worst time to wade in, but ...

--- Eric Wilhelm <scratchcomputing at gmail.com> wrote:

> no.  "my" inherit mechanism is disposable, but not without an
> adequate 
> replacement.  If you're using "inheritance sucks" to judge all of my 
> decisions, that's a bad metric.

It's a great metric if you have multiple extensions which don't play
well together.
 
> >and allows plugins to inject arbitrary options to App::Prove.
> 
> Yes.  At least to some extent.

I have no problem with arbitrary options being added to App::Prove as
long as some collision detection/resolution mechanism is provided. 
That's what I think we do not currently have.

> >I'm not aware that we've agreed on that.
> 
> That's a different discussion.
> 
> The simple fact is: Getopt::Long breaks error handling.  It does an 
> unchecked eval.  Do I really need to defend this?

I haven't looked into Getopt::Long too much. Can you point to the
section of the code in there which worries you?

> >I don't like the idea of plugins adding options to App::Prove
> 
> That's a different discussion.

Again, I have no problem with plugins adding options so long as there
is a collision/resolution mechanism in place.  The end user needs to
have the problems explicitly explained along with at least a *hint* of
how to resolve them.

> Getopt::Long breaks error handling.  This means neither we nor
> plugins 
> can die() *anywhere* under *any* subref which is handed to it.  Do
> you 
> really want to have to keep that "action at a distance" in mind
> rather 
> than just ******* fixing it?

Can someone provide a clear example of this problem so that it can be
better understood?

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog     - http://use.perl.org/~Ovid/journal/