Thursday, November 29, 2007

perl: our vs use vars

B.6.5. The vars Pragma
In the rare case that you truly need a global variable while use strict is in effect, you may declare it with the vars pragma.[407] This package-scoped pragma tells Perl that you are intentionally using one or more global variables:

If your program will never be used with a version of Perl prior to 5.6, you should use the our keyword instead of the vars pragma.
use strict;
use vars qw/ $fred $barney /;

$fred = "This is a global variable, but that's all right.\n";


31.21. use vars

use vars qw($frobbed @munge %seen);

This pragma, once used to declare a global variable, is now somewhat deprecated in favor of the our modifier. The previous declaration is better accomplished using:

our($frobbed, @munge, %seen);

or even:
our $frobbed = "F";
our @munge = "A" .. $frobbed;
our %seen = ();

No matter which of these you use, remember that they're talking about package globals, not file-scoped lexicals.



8.232. vars

Pragma that, given a list of variable names, predeclares all variables in the list, making sure they are available to routines with delayed loading (e.g., routines loaded by the AutoLoader or SelfLoader). This allows you to use the variables under use strict. The vars pragma also disables warnings about typographical errors.
use vars qw($var1 @var2 %var3);

perl: special vars

$EVAL_ERROR
$@


The currently raised exception or the Perl syntax error message from the last eval operation. (Mnemonic: where was the syntax error "at"?)
Unlike $! ($OS_ERROR), which is set on failure but not cleared on success, $@ is guaranteed to be set (to a true value) if the last eval had a compilation error or run-time exception, and guaranteed to be cleared (to a false value) if no such problem occurred. Warning messages are not collected in this variable. You can, however, set up a routine to process warnings by setting $SIG{__WARN__} as described later in this section. Note that the value of $@ may be an exception object rather than a string. If so, you can still probably treat it as a string if the exception object has stringification overloading defined for its class. If you propagate an exception by saying: die if $@; then an exception object will call $@->PROPAGATE to see what to do. (A string exception merely adds a "propagated at" line to the string.)



$!
$OS_ERROR
$ERRNO

If used in a numeric context, yields the current value of the errno variable, identifying the last system call error. If used in a string context, yields the corresponding system error string.



$@
$EVAL_ERROR

The Perl syntax error message from the last eval command.