Name of variable is value of other variable

[Gunnar Hjalmarsson]

How can I rewrite this code so that it works for whatever value $pp
may hold ?

if ($pp eq 'xx') { $myvar = $xx }
if ($pp eq 'yy') { $myvar = $yy }
if ($pp eq 'zz') { $myvar = $zz }

Basically, I am looking for something like:
$myvar = $"$pp";

Hashes seem the best choice, but I didn't find a way to put a
variable's name in it.

%hash = ( xx => 1, yy => 2, zz => 3 );
$myvar = $hash{$pp};

 

[Bart Van der Donck]

How can I rewrite this code so that it works for whatever value $pp
may hold ?

if ($pp eq 'xx') { $myvar = $xx }
if ($pp eq 'yy') { $myvar = $yy }
if ($pp eq 'zz') { $myvar = $zz }

Basically, I am looking for something like:
$myvar = $"$pp";

Hashes seem the best choice, but I didn't find a way to put a
variable's name in it.

Background: this goes back to a complex database construction that I
have to work with.

Thanks,
Bart

 

[Jürgen Exner]

How can I rewrite this code so that it works for whatever value $pp
may hold ?

if ($pp eq 'xx') { $myvar = $xx }
if ($pp eq 'yy') { $myvar = $yy }
if ($pp eq 'zz') { $myvar = $zz }

Basically, I am looking for something like:
$myvar = $"$pp";

NOT AGAIN!
This question has been asked before. Actually it has been Asked Frequently
(hint, hint).
Did you check
perldoc -q "variable name"
Did you check recent postings to the same topic?
Did you ask aunt google (search for symbolic reference or symref)?

Hashes seem the best choice,

Yes, they are.

but I didn't find a way to put a
variable's name in it.

You don't.
Use your own hash to store your data, not the the systems symbol table hash.

jue

 

[Tad McClellan]

Subject: Name of variable is value of other variable

^^^^ ^^^^^^^^

Those are known as "symbolic references", and they are Bad, they
can lead to hard-to-troubleshoot bugs so they should be avoided.

You are expected to check the Perl FAQ *before* posting to the
Perl newsgroup you know.

perldoc -q name
perldoc -q variable

How can I use a variable as a variable name?

How can I rewrite this code so that it works for whatever value $pp ^^^^^^^^^^^^^^
may hold ?

That is impossible.

$pp may hold the name of a variable that does not exist...

$pp may hold the name of a lexical variable (symrefs don't work
on lexicals).

if ($pp eq 'xx') { $myvar = $xx }
if ($pp eq 'yy') { $myvar = $yy }
if ($pp eq 'zz') { $myvar = $zz }

Basically, I am looking for something like:
$myvar = $"$pp";

If you _did_ want to use a symbolic reference (but you don't!),
then it would be:

$myvar = $$pp;

Hashes seem the best choice, but I didn't find a way to put a
variable's name in it.

The variable's "name" becomes the hash's "key":

if ($pp eq 'xx') { $myvar = $hash{xx} }

 

[Bart Van der Donck]

If you _did_ want to use a symbolic reference (but you don't!),
then it would be:
$myvar = $$pp;

I imagined $"$pp" (see previous) and it's amazing how perl pre-felt
that kind of reference I was thinking about.

Despite your advice, I 'm gonna take my chances on $$pp. I believe
this is most suited to what I 'm up to (my initial code was only a
simplification).

thanks Tad & the others
Bart

 

[Uri Guttman]

BVdD> I imagined $"$pp" (see previous) and it's amazing how perl pre-felt
BVdD> that kind of reference I was thinking about.

BVdD> Despite your advice, I 'm gonna take my chances on $$pp. I believe
BVdD> this is most suited to what I 'm up to (my initial code was only a
BVdD> simplification).

that isn't advice but very sage wisdom that you are ignoring. it is like
buying a gun and turning down a safety training course. you will shoot
yourself in the foot (or worse) if you use symrefs for ordinary data.

maybe this will convince you. do you realize that using symrefs is just
using the symbol table as a hash tree? and that the symbol table is just
a hash with special side effects? so using a regular hash is safer,
simpler, more flexible (you can have lexical hashes, assign anything to
any slot), handle references better, etc.

the ONLY reason to mung the symbol table is when you need to mung the
symbol table. it is NOT meant for use as a general purpose hash
tree. that is why strict disallows it.

now put down the gun and step back from the keyboard. listen to what
all experienced perl hackers will tell you. DO NOT USE SYMREFS FOR
ORDINARY DATA. do you get it? it is NOT simpler however much your brain
says it is.

you have been warned.

uri

 

[Tad McClellan]

Despite your advice, I 'm gonna take my chances on $$pp. I believe
this is most suited to what I 'm up to

You are making the wrong decision.

You don't need symrefs, you can do just what you want by
using a hash directly rather than shoe-horning your way
into the Symbol Table hash.

You will introduce hard-to-find bugs by using symrefs.

Just say No!

 

[Brian McCauley]

Tad wrote:



Despite your advice, I 'm gonna take my chances on $$pp. I believe
this is most suited to what I 'm up to (my initial code was only a
simplification).

Unlike Tad and Uri I am not fanatically opposed to symrefs (and/or
eval). There are cases where the convienence is worth the hazards
implicit in using such a powerfull and hard to control tools.

However I'm ~99% sure this is not such a case.

If you won't accept the advice not to use symrefs from people who always
advise against symrefs then please accept the advice of someone who
doesn't always advise against symrefs. Don't do it.

 

[Uri Guttman]

BM> Unlike Tad and Uri I am not fanatically opposed to symrefs (and/or
BM> eval). There are cases where the convienence is worth the hazards
BM> implicit in using such a powerfull and hard to control tools.

i would like to see such a case where the goal is not to mung the symbol
table and is only for data structure purposes. if the symtable is just a
hash, then symrefs are just an alternate syntax to mung hash trees. and
the minor possible golf benefits of the symref syntax over regular
hashes is not worth the danger. and as i and others have said many
times, regular hashes have many advantages over symrefs but symrefs have
only two features, it mungs the symbol table (very needed) and a diff
syntax from hashes (not important).

BM> If you won't accept the advice not to use symrefs from people who
BM> always advise against symrefs then please accept the advice of
BM> someone who doesn't always advise against symrefs. Don't do it.

so when do you advise their use?

and i hope we haven't lost this newbie to the 7th hells of symrefs.

we need more than mjd's var var stuff and the faq entry. i have posted
many times on this with stuff that isn't mentioned in either place
(notably that the symtable is just a hash tree with side effects). this
question is coming up way too often these days.

uri

 

[Brian McCauley]

BM> Unlike Tad and Uri I am not fanatically opposed to symrefs (and/or
BM> eval). There are cases where the convienence is worth the hazards
BM> implicit in using such a powerfull and hard to control tools.

i would like to see such a case where the goal is not to mung the symbol
table and is only for data structure purposes.

OK, there aren't any. I was just trying to con the OP into doing the
right thing.

Well that's not entirely true. I tend to think of symrefs and
eval(STRING) togeter and I was really thinking of eval.

I can't honestly recall the last time I ever used or suggested anyone
else should use a symref other than a CODEref of a GLOBref.

BM> If you won't accept the advice not to use symrefs from people who
BM> always advise against symrefs then please accept the advice of
BM> someone who doesn't always advise against symrefs. Don't do it.

so when do you advise their use?

The only time I ever suggest use of symrefs is other than for doing
AUTOLOAD/import stuff is that there are some cases where using a Perl
package (special hash) as a dispatch table can aid readability. Indeed
Perl does this itself in its implementation of OO.

and i hope we haven't lost this newbie to the 7th hells of symrefs.

I hope so too.

 

[Uri Guttman]

BM> OK, there aren't any. I was just trying to con the OP into doing the
BM> right thing.

ignore the man behind the curtain!

BM> Well that's not entirely true. I tend to think of symrefs and
BM> eval(STRING) togeter and I was really thinking of eval.

well, i think of them as very separate things though you can do the
equiv of symrefs with eval. i use string eval for code generation (see
Sort::Maker for a load of that) and for other rarities like
'use/require' at runtime without having to mung module names ( s{::}{/}g
kinda stuff).

BM> The only time I ever suggest use of symrefs is other than for doing
BM> AUTOLOAD/import stuff is that there are some cases where using a Perl
BM> package (special hash) as a dispatch table can aid readability.
BM> Indeed Perl does this itself in its implementation of OO.

even for dispatch tables i prefer a regular hash. checking for existance
is cleaner than looking in the symbol table. unless code is written
always expecting those subs to be there, i would stay away from
exporting dispatch subs.

uri

 

[Bart Van der Donck]

[..]
maybe this will convince you. do you realize that using symrefs is just
using the symbol table as a hash tree? and that the symbol table is just
a hash with special side effects? so using a regular hash is safer,
simpler, more flexible (you can have lexical hashes, assign anything to
any slot), handle references better, etc.

I have done further study and come to the same conclusion, yes.
Esp the links of a previous poster:
http://perl.plover.com/varvarname.html
http://perl.plover.com/varvarname2.html
http://perl.plover.com/varvarname3.html
Excellent article, clear style

[..]
it is NOT simpler however much your brain says it is.

Symrefs are new for me. They seemed suitable at first sight for what I
wanted to do. After studying, one must conclude they are simply too
dangerous to use in production environment.

it's a trap! AAAARRGHHH!!!
Bart

 

[Uri Guttman]

BVdD> Esp the links of a previous poster:
BVdD> http://perl.plover.com/varvarname.html
BVdD> http://perl.plover.com/varvarname2.html
BVdD> http://perl.plover.com/varvarname3.html
BVdD> Excellent article, clear style

those are good which is why we point newbies to them all the time. did
you think you were the first one ever to try symrefs and be told they
are evil?

BVdD> Symrefs are new for me. They seemed suitable at first sight for
BVdD> what I wanted to do. After studying, one must conclude they are
BVdD> simply too dangerous to use in production environment.

BVdD> it's a trap! AAAARRGHHH!!!

yep and at least you finally listened and read up and learned. let this
be a lesson to other newbies who get seduced by the sirens of
symrefs.

uri