in reply to Testing $^W

Turning off warnings without turning them back on is a pretty-darn-bad practice.
I'd say that any manual "turning warnings back on" is very bad practise. Even if you don't use use warnings (which has been available for more than 5 years), turning off warnings should be done by using a localized value for $^W, so the old value of $^W will be restored - no matter what the old value was, and no matter how the block is left. 
  is( $^W, 1, 'warnings are on' );
  third_party_code();
  is( $^W, 1, 'warnings are still on' );

[download]
That's only half of your tests, isn't it? What's missing is: 
   {   local $^W;
       third_party_code();
       ok (!$^W, 'warnings still off');
   }

[download]
after all, you want to test that a piece of code leaves $^W as is.

But then, why stop at testing $^W? How about $*? $"? @ARGV?, %SIG? $package::var?

Perl --((8:>*

Replies are listed 'Best First'.
Re^2: Testing $^W
by Anonymous Monk on Nov 04, 2005 at 18:39 UTC
    But then, why stop at testing $^W? How about $*? $"? @ARGV?, %SIG? $package::var?

    I think you meant this in jest, but this would be a very valuable resource if it could be automated; kind of like the sort of utility that tests for memory leaks in C.

    Just being able to know that a given module has tampered with your { global variables/function definitions/namespaces/whatever} is very, very handy.

    Perl gives you a lot of rope to hang yourself (and others!) with; having tools to keep it coiled neatly would really be nice sometimes. :-)
    --
    Ytrew

[reply]
      That's a great idea! I think you could add a Policy to Perl::Critic that warns you if a global or package variable was modified without being localized first.
[reply]

In Section Meditations