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