in reply to Re: Re: Re: Runtime Hash Variable access
in thread Runtime Hash Variable access

It is not deprecated, it is not allowed by strict 'refs'; these are different things. Of course, since you are strongly advised to use strict (which includes strict 'refs') as a default, you might say that symbolic references are deprecated. As to why symbolic refs are discouraged, the reasons are that (a) they don't work with variables declared with my -- which will usually be the majority of the variables you use if you use strict, and (b) their functionality is provided by mechanisms that don't require you make assumptions about your program's runtime environment (you won't always know that the variable you're trying to use as the name of another variable really is). See for a short account of why you should use strict, and perlref for the story about symbolic references.

You are of course allowed to do it, if you know what you are doing (by disabling strict 'refs' in a code block where you do that. But if you ever find yourself tempted to do this, ask yourself whether there's a way around it first. As an illustration of point (a), the following version will not do what you want it to do:

#!/usr/bin/perl use warnings; my $foo = "what?"; my $bar = "foo"; print $$bar;
(if you run it, you'll see that you get an "uninitialized value" warning on the print line) -- because that $$bar is supposed to point to $main::foo, which is distinct from my $foo.

To go to your example, why not code it with a hash?

my %vars = ( the_var_i_want => 'this is the actual value' ); chomp (my $the_name = <STDIN>); print $var{"${the_name}_i_want"};

The language provides many tools for working with the contents of hashes. You can put all the variables you need to access based on runtime values in hashes, and get all the functionality you get with symbolic references; with hashes, you can even easily find similar names, for example.

If not P, what? Q maybe?
"Sidney Morgenbesser"