in reply to Triggering 'strict' from within a package

strict.pm is one of the simplest modules in the Perl distribution. Just copy the functionality in your custom package. 
package Custom::Package;

sub import {
    $^H |= 0x604 unless $ENV {ENV} eq "PR";
}
sub unimport {
    $^H &= ~ 0x604 unless $ENV {ENV} eq "PR";
}
1;

[download]
Assuming you use the ENV environment variable to flag a production environment.

Don't believe those who claim it cannot be done - this is only one of the ways how to do it.

But I'd like to know why you want to turn off strictness in production code.

Abigail

Replies are listed 'Best First'.
Re: Re: Triggering 'strict' from within a package
by kal (Hermit) on Aug 12, 2002 at 16:07 UTC

    Hmm, $^H, that's the one with "don't cross the streams" written all over it, isn't it? :) I think I prefer tye's solution, although you've given me another lesson (always check the module). I had mistakenly assumed there wouldn't be a strict.pm, since it was just a pragma, although I was slightly confused in Exporter.pm when I saw there was no code to handle the pragmas differently.

    As for turning off strict, it's mainly about keeping the webserver log files clean - we do a lot of traffic analysis on the log files (even the error logs), and Perl error messages can sometimes screw it up. Plus, we have an alternative system for collecting error messages and assertion failures. It's not as tight as strict, but that's the opportunity cost.

    Thanks!

[reply]
      But Perl doesn't know pragmas. It's not a thingy in the language itself. It's just there for humans. The language really doesn't care whether you use a capital letter in the first argument to a use statement or not.

      As for tye's solution, that's neat, although I think I prefer to use goto &strict::import - just in case a future version would start using caller.

      Abigail

[reply]
[d/l]
[select]

      I still don't understand. Is there any case where strict merely produces a warning?

      I was under the impression that strict's only effect was to cause the compilation phase to fail if it didn't like the code. Are you sure you are not confusing strict with warnings? Or did I miss something?

[reply]

        strict.pm has run-time as well as compile-time checks. For example, symbolic references can only be detected at run time.

        I consider dereferencing a symbolic reference to be an indication of a pretty serious error (if you wrote and tested the code under 'use strict') that I'd want that flagged in production. I fully support turning off warnings in production (though I even more support keeping warnings turned on and providing a system for the warnings to get routed to the developers so they can be "fixed").

        FWI, I can't think of any warnings that are controlled by strict.pm, but that doesn't mean there aren't any. (:

                - tye (but my friends call me "Tye")
[reply]
        I still don't understand. Is there any case where strict merely produces a warning?

        What I'm talking about is strict failing a program at run-time, and then dumping stuff in the logs, viz:

        Global symbol "$foo" requires explicit package name at /home/user/www/test.pl line 10.

        .. it's getting rid of that kind of stuff that I'm talking about (I don't think warnings makes any difference in that case?)

[reply]
      > it's mainly about keeping the webserver log files clean

      But if you get your script working on the stage server, before moving it to the production server your 'use strict' shouldn't add anything to your webserver logs. Unless I'm mistaken, which did happen once before.

[reply]

In Section Seekers of Perl Wisdom