I agree with Hofmator here. use diagnostics is a very good idea ... for a person still learning Perl. For those of us who've been with it hardcore for over a year, the extra verbiage isn't worth the extra execution time. (And extra RAM, though that's usually less of an issue.)
I would add use 5.6.0; to that list. This makes sure that our and other nifty-pretties from 5.6.0+ are supported. If they're not, you'll know immediately why.
My header almost always looks like:
use 5.6.0;
use strict;
use warnings;
Then, I can always comment out warnings, if I wanted to.
------
/me wants to be the brightest bulb in the chandelier! | [reply]
[d/l]
[select] |
use warnings; and perl -w are not the same thing. | [reply]
[d/l] |
use warnings; and perl -w are not the same thing.
I'm aware of that, the different scoping, the possibility to use warnings::register; ... but the way I understand it, use warnings; is not reasonable after setting
$^W = 1; # equivalent to perl -w which is done by use diagnostics;. Please correct me if I'm overlooking something here...
-- Hofmator
| [reply]
[d/l]
[select] |
Myth: use warnings is not reasonable after using -w or setting $^W=1.
In the scope of lexical warnings, the old warning state is ignored. According to perllexwarn,
If you are used with working with a version of Perl prior to the introduction of lexically scoped warnings, or have code that uses both lexical warnings and $^W, this section will describe how they interact.
How Lexical Warnings interact with -w/$^W:
- If none of the three command line flags (-w, -W or -X) that control warnings is used and neither $^W or the warnings pragma are used, then default warnings will be enabled and optional warnings disabled. This means that legacy code that doesn't attempt to control the warnings will work unchanged.
- The -w flag just sets the global $^W variable as in 5.005 -- this means that any legacy code that currently relies on manipulating $^W to control warning behavior will still work as is.
- Apart from now being a boolean, the $^W variable operates in exactly the same horrible uncontrolled global way, except that it cannot disable/enable default warnings.
- If a piece of code is under the control of the warnings pragma, both the $^W variable and the -w flag will be ignored for the scope of the lexical warning.
- The only way to override a lexical warnings setting is with the -W or -X command line flags.
The combined effect of 3 & 4 is that it will allow code which uses the warnings pragma to control the warning behavior of $^W-type code (using a local $^W=0) if it really wants to, but not vice-versa.
So, go ahead and use warnings and selectivly enable/disable things as you need. The presence of -w on the command line (or explicit setting of the global flag) will not bother you.
Code outside of yours will continue to use the -w state; yours (containing use warnings) will hide that and use what you asked for. The hiding of -w by use warnings is itself lexically scoped.
Also, as specifically pertains to diagnostics.pm, Paul Marquess notes "I *think* I've got diagnostics to work with the lexical warnings
patch, but there were design decisions made in diagnostics to work
around the limitations of C<$^W>. Now that those limitations are gone,
the module should be revisited."
| [reply]
[d/l]
[select] |