664, 668 - Getopt::Long

[Eric Wilhelm z]

# from Andy Armstrong on Wednesday 03 October 2007 02:05:

>On 3 Oct 2007, at 08:39, Eric Wilhelm wrote:
>> So, Getopt::Long does local $SIG{__DIE__} = "__DEFAULT__" and then
>> eval, and then print STDERR $@ unless the $@ is "!FINISH".  This
>> basically means that error propagation is impossible without a
>> workaround. 
>>
>> This hack means that subrefs in the options can die to stop option
>> processing.  While they could exit(1) if this were not an API, this
>> is an API, so...  It also means bad options and thrown errors are
>> different.
>
>We don't have subrefs in the options though...

Yes we do, and plugins will too.  It already bit us that we can't 
bail-out in _help() (if Pod::Usage is unavailable) without calling 
exit().  Calling exit() in a Module::API is *bad*.

# from Andy Armstrong on Wednesday 03 October 2007 02:07:
>Can you give is some hint as to why you want to do this?

# from Andy Armstrong on Wednesday 03 October 2007 02:35:
>On 3 Oct 2007, at 08:52, ewilhelm at hexten.net wrote:
>> lib/App/Prove.pm - refactor to localize GetOptions() weirdness
>I'm not clear why we need this.
>
>I'm reverting the changes pending discussion.

Gah!  I get 30 minutes in my sleep to defend my commit?  Please imagine 
that I might have a decent reason and let it stand unless it is 
actually in the way.  I commented this, explained it on the mailing 
list, and tested it against all of our compatibility targets.

The reason for localizing the Getopt::Long::GetOptions() call is pretty 
straightforward.  It separates the declarations of @options from the 
parsing of them, and makes it easier to replace Getopt::Long with 
something non-broken should said non-broken option parser be available.

Please restore these changes.  They test clean against 5.5.4 and allow 
us to avoid explaining in the documentation that the Getopt::Long
"necessary evil because it is core" borked dependency breaks "perl 5" 
code.

--Eric
-- 
"Left to themselves, things tend to go from bad to worse."
--Murphy's Corollary
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------