On Thu, Jun 18, 2009 at 2:11 PM, Jonathan Rockway<j...@jrock.us> wrote:
> * On Tue, Jun 16 2009, Bill Ward wrote:
>> I'm more interested (at $JOB) in global warnings, actually. Of course
>> one can enable those with $^W or "perl -w" and I do, but developers
>> ignore the warnings all too often. Many of our core modules were
>> written without warnings enabled, and people are slow to fix those
>> warnings. So, we want to make warnings fatal in the development
>> environment to force developers to fix those niggling "uninitialized
>> value" warnings that are all over the place in our log files.
>
> Honestly, I think this is worth bringing up on p5p. I think it should
> be possible to convince perl to give user code control over the hints
> hash as each scope is compiled.
>
> I tried the obvious technique of:
>
> package forcewarn;
> use strict;
>
> use B::Hooks::OP::Check::StashChange;
>
> our $id = B::Hooks::OP::Check::StashChange::register(sub {
> my ($new, $old) = @_;
> warn "compiling $new";
> warnings->import( FATAL => 'all' );
> });
>
> 1;
>
> And then "use forcewarn" before any of my code compiled, but the
> warnings->import only seems to affect the calling scope, not the scope
> currently being compiled.
Without reading B::Hooks::OP::blah to know how it works, I notice
you're calling import from the forcewarn package, not the package you
want to affect. Consider:
eval "
package $target_package;
warnings->import( FATAL => 'all' );
"
instead. Also, you should require warnings if you're going to call a
method on it. I know you probably already have it loaded but it's good
practice.
Josh
