Re: Re: Triggering 'strict' from within a package

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!

Comment on Re: Re: Triggering 'strict' from within a package

Replies are listed 'Best First'.
Re: Triggering 'strict' from within a package by Abigail-II (Bishop) on Aug 12, 2002 at 16:29 UTC
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]
Re: Re: Re: Triggering 'strict' from within a package by mirod (Canon) on Aug 12, 2002 at 16:19 UTC
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]
(tye)Re2: Triggering 'strict' from within a package by tye (Sage) on Aug 12, 2002 at 16:27 UTC
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]
Re: Re: Re: Re: Triggering 'strict' from within a package by kal (Hermit) on Aug 12, 2002 at 17:11 UTC
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]
Re^5: Triggering 'strict' from within a package by Aristotle (Chancellor) on Aug 12, 2002 at 23:36 UTC
This is no reason to disable strictures, it is a reason to use CGI::Carp's `carpout()` or `set_message()` functions. Disabling strictures is a serious mistake especially on a production server where failing a stricture at runtime should be indicative of a critical bug. In such a case, you want strict to scream bloody murder and kill your script rather than the script being able to run on and silently throw sand into your machinery. Makeshifts last the longest.	[reply]
Re: Re: Re: Triggering 'strict' from within a package by BigLug (Chaplain) on Aug 13, 2002 at 06:40 UTC
> 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]