664, 668 - Getopt::Long

Eric Wilhelm scratchcomputing at gmail.com
Thu Oct 4 22:07:58 BST 2007


# from Andy Armstrong
# on Thursday 04 October 2007 13:22:

>On 4 Oct 2007, at 21:15, Eric Wilhelm wrote:
>> Forget that I ever said "plugins".  Just tell me why we want to
>> have to keep in mind that Getopt::Long breaks error handling and what
>> justifies App::Prove calling exit() because of it.
>
>I've just noticed this:
>
>             (     App::Prove::Plugins->can('switches')
>and it's making it difficult to forget that you said "plugins" :)

That was a different commit, labeled as "just a sketch", put to the list 
for discussion (which didn't happen) and I've said about 10 times now 
that it is a different discussion.

>We have three sub refs in the options hash. None of them need to be
>there - that code can easily be refactored to avoid them. We're not -
>as far as I know - planning to add more. We don't have any more of
>problem with Getopt::Long than anyone else who uses it does. Ergo we
>don't need to fix it.

The refactor is an implicit workaround and assumes that the plan will 
not change.  The fix doesn't get in the way and the localization makes 
the code cleaner.  Dismissing it as "not a problem" just leaves the 
possibility that it could become a problem.

Would you tell me I'm wrong if I said "setting local $SIG{__DIE__} and 
doing an unchecked eval" is a bad thing and should be removed from the 
App::Prove::GetOptions module?  If not, pretend we're talking about the 
App::Prove::GetOptions module.  If so, I give up.

--Eric
-- 
The reasonable man adapts himself to the world; the unreasonable man
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man.
--George Bernard Shaw
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------


More information about the tapx-dev mailing list