My suggestion is that you simply refrain from including use warnings in your module. It is true that I'm not one of the people who justify not caring about backward compatability by disparaging people who don't update Perl for an entire millenium :), but I think you should avoid this more than just because of problems with backward compatability.
First, it is a good thing® to utilize warnings to help you notice mistakes in your modules. This might lead you to think that you should use warnings in your module. But I accomplish this by using #!/usr/bin/perl -w in my test scripts (and perhaps other scripts that I use when developing the module). It works better because it shows me warnings in the code that is using the module and (most of) the code in other modules that my module uses.
"But there's no harm in doing use warnings in my module, right?" you ask. Actually, there is harm.
Before I continue, let me note that I'm only talking about utilizing use warnings to enable the production of warnings by the module's code. There certainly are other reasons to utilize the warnings.pm pragma. And if there are any other beneficial effects of a simple use warnings; in a module, then please let me know.
I'm a strong believer in enabling warnings during development. But I find that in most production situations, Perl's warnings are better left disabled.
A warning is only useful if it makes it to a person who can understand it and address the problem that created it. In development, warnings are useful because they are sent directly to the developer. But most production environments don't have a good channel set up for delivering any warnings generated to a developer's attention, much less to the appropriate developer's attention.
So in most production environments, Perl warnings are mostly useless and can cause problems like confusing your users, obscuring important information in a flood of relative trivia, or even just consuming too many resources.
So even for non-module code, I use -w during development and drop the -w when deploying to production. But me dropping -w doesn't stop any use warnings-using module from generating warnings.
So I think a module should only use warnings if its test suite includes cases of passing in undef for every parameter that could reasonably be an empty string or zero (and also does its best to test for other sources of warnings from the module code caused, in part, by what the module user passed in).
It can often be a reasonable style choice to use undef when any empty string or zero is wanted. So it is a disservice to have a module that generates warnings when such an undef is passed to it (unless -w is in effect).
- tye
In reply to Re: Backward compatible lexical warnings (don't)
by tye
in thread Backward compatible lexical warnings
by xdg
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |