Re^3: Variable declaration in 'required' file doesn't work under 'strict'?

Rather than using the vars pragma, I would recommend using package variables:

In what way are variables declared with the vars pragma not package variables?

This will prevent you from accidentally updating your config variables from your script.

It will also prevent you from accessing the keys of the %state_name_for hash, since in your last example it is a lexical scoped my variable not visible in config.pl.

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Comment on Re^3: Variable declaration in 'required' file doesn't work under 'strict'? Select or Download Code

Replies are listed 'Best First'.
Re^4: Variable declaration in 'required' file doesn't work under 'strict'? by agianni (Hermit) on Mar 12, 2007 at 12:57 UTC
In what way are variables declared with the vars pragma not package variables? Sorry, you're right, the vars pragma does indeed make the variables part of the main package. What I meant to suggest is that making them part of an explicit package other than main makes code more readable. it will also prevent you from accessing the keys of the %state_name_for hash, since in your last example it is a lexical scoped my variable not visible in config.pl. Again, I wasn't clear that I was suggesting that the MyConfig package is declared in the config.pl file. %state_name_for is declared as lexically scoped precisely to avoid making it available from outside of the package. Instead, package users should use the state_name_for subroutine to access it. This will help coders avoid this pitfall: `if( $MyConfig::state_name_for{AL} = 'Alaska' ){ print "oops! we just assigned Alaska to the AL key!\n"; }` [download]	[reply] [d/l]
Re^5: Variable declaration in 'required' file doesn't work under 'strict'? by Anno (Deacon) on Mar 12, 2007 at 13:27 UTC
Instead, package users should use the state_name_for subroutine to access it. This will help coders avoid this pitfall: `if( $MyConfig::state_name_for{AL} = 'Alaska' ){ print "oops! we just assigned Alaska to the AL key!\n"; }` [download] But your `state_name_for` is defined `sub state_name_for{ return \%state_name_for; }` [download] That returns a reference to the hash `%state_name_for` and exposes it to the user just like accessing the hash directly. To protect the hash, put something like this in `MyConfig`: `sub get_state_name { $state_name_for{ +shift} }` [download] and keep `%state_name_for` a private lexical in `MyConfig`. Now the user can't change the hash content, accidentally or deliberately. They still can query the hash the way it is intended. Anno	[reply] [d/l] [select]