Re^4: symbol table vs. eval

yes but imagine the following situation

include_file.pl (this is the only file I can edit)

my $test="my_variable_name";  # I pulled this from the db.  I have no 
+idea what it actually is, plus I need to be able to support arbitrary
+ additions to the db anyway
my $default_value="the value I set";
$$test = $default_value;
[download]

module.pm (I can't touch this file)

use strict;
package apackage;
do "include_file.pl";
print "the value of \$my_variable_name = $my_variable_name\n"; # I can
+'t control the fact that this variable is being referred to without i
+ts package name
[download]

script.pl (this is the code that will be run. I also can't touch it)

use strict;
use module;
$my_variable_name = "A new value";
print "the value of \$my_variable_name = $my_variable_name\n"; #print 
+the local value
print "the value of the package variable = $apackage::my_variable_name
+\n"; # print the package value
[download]

The question is how do I while only modifying the include file avoid failing use strict. While still allowing the module file to access the variable by name directly and the script file to access it by package.

Comment on Re^4: symbol table vs. eval Select or Download Code

Replies are listed 'Best First'.
Re^5: symbol table vs. eval by ikegami (Patriarch) on Feb 23, 2006 at 19:37 UTC
There more than one kind of strict errors. Undeclared variables will lead to strict errors. `my` and `our` help fix these errors. However, the error in `include_file.pl` is not caused by undeclared variables. It's caused by using symbolic references. It's possible to write code that fetches a reference to a symbol while being strict-friendly, but it's much simple to temporarily disable checks for symbolic references. That can be done as follows: `# include_file.pl # Pulled from the DB. my $test = "my_variable_name"; my $default_value = "the value I set"; my $var_ref = do { no strict 'refs'; \${$test} }; $$var_ref = $default_value;` [download] By the way, `script.pl` doesn't compile. I'm going to assume your real `script.pl` doesn't have that problem.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: symbol table vs. eval
by ikegami (Patriarch) on Feb 23, 2006 at 19:37 UTC

There more than one kind of strict errors. Undeclared variables will lead to strict errors. my and our help fix these errors. However, the error in include_file.pl is not caused by undeclared variables. It's caused by using symbolic references. It's possible to write code that fetches a reference to a symbol while being strict-friendly, but it's much simple to temporarily disable checks for symbolic references. That can be done as follows:

# include_file.pl

# Pulled from the DB.
my $test          = "my_variable_name";
my $default_value = "the value I set";

my $var_ref = do { no strict 'refs'; \${$test} };

$$var_ref = $default_value;
[download]

By the way, script.pl doesn't compile. I'm going to assume your real script.pl doesn't have that problem.

[reply]
[d/l]
[select]