Re: Trying to create a common "variable library"

The low-tech solution would be

# the "variable library", e.g. MyVars.pm

use vars qw($scalar @array %hash);

$scalar = "Foo";
@array = qw(Foo Bar);
%hash = (Foo => "Bar");
1;
[download]

#!/usr/bin/perl -l
use strict;
use warnings;
use MyVars;

print $scalar;
print "@array";
print "$_ => $hash{$_}" for keys %hash;
[download]

The ugly thing is (why I called it low-tech) that you have to mention all variables twice (because of the use vars) — but for "a dozen" variables this should be doable.

Comment on Re: Trying to create a common "variable library" Select or Download Code

Replies are listed 'Best First'.
Re^2: Trying to create a common "variable library" by fullermd (Priest) on Jul 21, 2010 at 00:38 UTC
`use vars qw($scalar @array %hash);` [download] % perldoc vars NOTE: For variables in the current package, the functionality provided by this pragma has been superseded by "our" declarations, available in Perl v5.6.0 or later. See "our" in perlfunc. It's only a few more words to make a proper MyVars module out of it. `package MyVars; our @ISA = qw(Exporter); our @EXPORT = qw($scalar @array %hash); [...]` [download]	[reply] [d/l] [select]
Re^3: Trying to create a common "variable library" by almut (Canon) on Jul 21, 2010 at 05:03 UTC
... the functionality provided by this pragma has been superseded by "our" declarations ... The thing is that the extra file implies a separate lexical scope, so you can't use `our` (without additional hoops), because its effect is lexically scoped. Even if the docs call `use vars` "superseded", it still has its occasional uses, because the functionality isn't the same as "`our`" in every respect. In the particular case of what the OP wants to use this for (i.e. having some common variable definitions to be included in several scripts), I don't really see an advantage of creating a "proper" module as you call it, i.e. putting the global variables in a different namespace first, only to then alias them all into the current package using Exporter. As long as there's nothing else in the module, where's the benefit?	[reply] [d/l] [select]
Re^4: Trying to create a common "variable library" by fullermd (Priest) on Jul 21, 2010 at 13:57 UTC
Even if the docs call use vars "superseded", it still has its occasional uses, because the functionality isn't the same as "our" in every respect. No, that's what Exporter is for. As long as there's nothing else in the module, where's the benefit? In this very specific, narrow case, probably not much. But specific, narrow cases have very bad habits of becoming general, larger cases on their own, as well as being physically or mentally cut&pasted into larger cases. So when the cost of doing it "cleanly" is so small (one `package` line and two Exporter lines), I think it's well worthwhile.	[reply] [d/l]
Re^2: Trying to create a common "variable library" by ikegami (Patriarch) on Jul 20, 2010 at 23:42 UTC
Use do rather than require (via `use`) when the "module" doesn't have a package statement.	[reply] [d/l]
Re^3: Trying to create a common "variable library" by almut (Canon) on Jul 21, 2010 at 05:22 UTC
It's maybe worth noting that the `do` would need to be put in a BEGIN block to have it execute at compile time `BEGIN { do "MyVars.pm" }` [download] And for anyone unsure what the difference is: in contrast to `require`, `do` doesn't keep track of what's already been loaded — which could make a difference if you `use MyVars` several times (in different namespaces) in the same script/program.	[reply] [d/l] [select]
Re^2: Trying to create a common "variable library" by tbblake (Initiate) on Jul 20, 2010 at 19:43 UTC
Perfect, my module-foo has never been that good since I'm more of a unix SA who uses perl to do his job, than a perl programmer. Thanks!! http://pastebin.com/QTtvmXzj	[reply]


Your skill will accomplish what the force of many cannot
	PerlMonks