Use a variable value in another variable's name

[Robin Corcoran]

I'm trying to use the value of one variable in the name of another variable.

I have a while loop which matches every table in my document and I want to
record something for each table. I'm using one variable to count the tables

my $tableCount++;

I want to use the value of that variable in creating another variable.

my $table_$tableCount_cols="5"; #I want to create a var called
$table_2_cols

I've messed around using {} to isolate each variable, but I don't think I
have it quite right. I can't find anything in the FAQ's that cover this, and
any help would be appreciated.

Thanks,

Robinshane

 

[Robin Corcoran]

Thanks Bernard. What I'm actually trying to do is create an array of the
column widths for each table that I find. I wanted an array called

@Table_2_cols

Where each one would have a number of elements
$table_2_cols[0]="50pt"
....
$table_2_cols[9]="75pt"

Would this still be a bad idea? Can you suggest something insead?

Thanks very much,

Robinshane

 

[A. Sinan Unur]

[ top-posting fixed. please don't do that. ]

Thanks Bernard. What I'm actually trying to do is create an array of
the column widths for each table that I find. I wanted an array called

@Table_2_cols

Where each one would have a number of elements
$table_2_cols[0]="50pt"
...
$table_2_cols[9]="75pt"

Would this still be a bad idea?

Did you actually read the docs above? Of course it is a bad idea.

Can you suggest something insead?

Did you actually read the docs above?

my %cols = (
table_1 => [ '50pt', '75pt' ],
table_2 => [ '50pt', '75pt' ],
);

 

[Jürgen Exner]

I'm trying to use the value of one variable in the name of another
variable.

Very bad idea. Please see Google for previous discussions about this topic.

[...]

I can't find anything in the FAQ's that cover this

perldoc -q "variable name"

jue

 

[Robin Corcoran]

This example shows using a variable name in another variable, which isn't
what I want to do. I want to use a variable to build up the *name* of
another variable.

$count=2;
$Table_$count="Test" #want a var called "Table_2"


thanks,
robinshane

I'm trying to use the value of one variable in the name of another
variable.

Very bad idea. Please see Google for previous discussions about this topic.

[...]
I can't find anything in the FAQ's that cover this

perldoc -q "variable name"

jue

 

[Tore Aursand]

I'm trying to use the value of one variable in the name of another
variable.

Good thing you haven't figured how to do it, 'cause it's not what you want
at all.

I have a while loop which matches every table in my document and I want
to record something for each table. I'm using one variable to count the
tables

my $tableCount++;

I want to use the value of that variable in creating another variable.

my $table_$tableCount_cols="5"; #I want to create a var called
$table_2_cols

Don't. Seriously. Consider using a better approach. just an example:

my %table = ();
for ( 1..10 ) {
$table{$_}->{'cols'} = 5;
}

 

[Paul Lalli]

I'm trying to use the value of one variable in the name of another
variable.

Very bad idea. Please see Google for previous discussions about this topic.

[...]
I can't find anything in the FAQ's that cover this

perldoc -q "variable name"

jue

This example shows using a variable name in another variable, which isn't
what I want to do. I want to use a variable to build up the *name* of
another variable.

$count=2;
$Table_$count="Test" #want a var called "Table_2"


thanks,
robinshane

First, please stop top posting. I'm not the first person to make this
request of you. That means stop posting your replies above what you're
replying to.

Second, yes, we know what you want to do. Everyone's trying to tell you
that's a A BAD IDEA. The example in perldoc -q 'variable name' is telling
you what you *should* be doing instead. Do not use a variable's value as
(part of) another variable's name. It's BAD. Instead, do as the FAQ
suggested and use either an array or hash:

$count = 2;
$Table[$count] = 'Test';

Paul Lalli

 

[Keith Keller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This example shows using a variable name in another variable, which isn't
what I want to do. I want to use a variable to build up the *name* of
another variable.

The first line in that perldoc FAQ says:

Beginners often think they want to have a variable contain
the name of a variable.

But perhaps it *should* say

Beginners often think they want to have a variable name
contain the name of another variable.

Because that's more like what it describes. Please read it again
in that context.

- --keith

- --
(e-mail address removed)-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA/+E2hVcNCxZ5ID8RAuFWAJ9zwHwiS4OtwyyOIROEdO/LVRq5sQCdGIuK
MsNp/1DveMz6GqDR9efgEiw=
=U37q
-----END PGP SIGNATURE-----

 

[Jürgen Exner]

[Please do not top-post! Please do not blindly fullquote]
[Trying to correct but because of your posting style I can only guess what
you mean by "this example"]

This example shows using a variable name in another variable, which
isn't what I want to do. I want to use a variable to build up the
*name* of another variable.

The difference is irrelevant.
The FAQ describes the simplified case, where the value of the variable is
concatenated with nothing to be used as name of the second variable.
You want to concatenate the value of the first variable with some non-empty
text to use as the name of the second variable.

There is no difference in how to do that. And much more important: there is
no difference in why this is A BAD IDEA.

$count=2;
$Table_$count="Test" #want a var called "Table_2"

What's wrong with using a hash or in your case as you have numbers using an
array?
Just do $table[2].

jue

 

[A. Sinan Unur]

[ top-posting fixed. stop doing this ]

I'm trying to use the value of one variable in the name of another
variable.

Very bad idea. Please see Google for previous discussions about this topic.

[...]
I can't find anything in the FAQ's that cover this

perldoc -q "variable name"

This example shows using a variable name in another variable, which isn't
what I want to do. I want to use a variable to build up the *name* of
another variable.

Huh? The distinction you are trying to make is so superficial that it leads
me to believe it is not worth trying to explain things to you.

 

[A. Sinan Unur]

....
....

Well, you don't want to use "my." And I hope you're not using

use strict;

either because that will mess everything up.

May I suggest considering not admitting to the world that you do not

use strict;

in your scripts?

Try this:

$tableCount=2;
${"table_${tableCount}_cols"}="5";
print $table_2_cols; # prints 5

Please do not do this. Have you read the other responses to this request
and looked at the documents provided? What you are doing is a BAD IDEA.

http://perl.plover.com/varvarname.html
http://perl.plover.com/varvarname2.html
http://perl.plover.com/varvarname3.html

perldoc -q "variable name"

Sheeesh!

 

[Robin Corcoran]

Please do not do this. Have you read the other responses to this request
and looked at the documents provided? What you are doing is a BAD IDEA.

http://perl.plover.com/varvarname.html
http://perl.plover.com/varvarname2.html
http://perl.plover.com/varvarname3.html

I have re-examined this based on everyone's advice and have decided to use
an array of arrays and skip the variable in the variable name.

I appreciate all of the advice from everyone and the point in the right
direction.

robinshane

 

[510046470588-0001]

This example shows using a variable name in another variable, which isn't
what I want to do. I want to use a variable to build up the *name* of
another variable.

$count=2;
$Table_$count="Test" #want a var called "Table_2"

one may use eval() for this purpose


Klaus Schilling

 

[Jürgen Exner]

one may use eval() for this purpose

Yes, TIMTOW to shoot yourself in the foot.
You just found another one.

jue

 

[Brian McCauley]

The difference is irrelevant.
The FAQ describes the simplified case, where the value of the variable is
concatenated with nothing to be used as name of the second variable.
You want to concatenate the value of the first variable with some non-empty
text to use as the name of the second variable.

There is no difference in how to do that. And much more important: there is
no difference in why this is A BAD IDEA.

That is untrue, there is a difference. That is to say there is one
additional reason why using data as a whole symref is BAD compared to
using it as part of a symref.

Using (potentially user-supplied) data as a _suffix_ of a variable
name is A BAD IDEA largely for the somewhat intagible reason given in
the FAQ that it "conflates the program-addressable namespace and the
user-addressable one".

To an experienced programmer this feels intuatively bad but actually
it's rather hard to put forward a hard reason for why it is in itself
bad.

The problem of variables accessed by symbolic reference clashing with
ones used in the program is not a real problem because of the prefix.

The problem of being restricted to global variables is not really as
much of an issue as people make out. From a programming point of view
a file-scoped-lexical variable is almost as global as a package-scoped
variable. Yeah, sure package variable _can_ be accessed from outside
their scope using a namespace qualifier but if you put this forward as
an advantage of file-scoped-lexical variable over package-scoped
variables then you are just being silly.

The problem that code using symbolic references is also usually
slightly slower than the equivalent code using a lexically scoped hash
is the main reason not to use symbolic references.

Now if we look at the example in the FAQ of using data as the _whole_
symref then we open up a whole other can of worms with the possibility
of symbolic references stomping all over your symbol table - either by
accident or with malicious intent.

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

 

[Jürgen Exner]

This example shows using a variable name in another variable, which
isn't what I want to do. I want to use a variable to build up the
*name* of another variable.

The difference is irrelevant. [...]
There is no difference in how to do that. And much more important:
there is no difference in why this is A BAD IDEA.

That is untrue, there is a difference.

[Long explanation snipped]

While all you wrote makes sense in reality there is pretty much no
difference between if you are run over by a bus or by an 18-wheeler.
So better not to use symbolic references.

jue

 

[Uri Guttman]

BM> The problem that code using symbolic references is also usually
BM> slightly slower than the equivalent code using a lexically scoped
BM> hash is the main reason not to use symbolic references.

small speed differences should never be the main reason to not use a
perl feature. symrefs are bad in so many ways that you don't have to
resort to that reason. my current simple response is that symrefs are
just using the symbol table as a hash tree (with special side effects)
so why no just use a proper hash tree on your own? then you can pass it
around, keep it safe, not worry about side effects, etc.

uri

 

[510046470588-0001]

small speed differences should never be the main reason to not use a
perl feature. symrefs are bad in so many ways that you don't have to
resort to that reason. my current simple response is that symrefs are
just using the symbol table as a hash tree (with special side effects)
so why no just use a proper hash tree on your own? then you can pass it
around, keep it safe, not worry about side effects, etc.

I was suggesting eval (), not symrefs.

Klaus Schilling

 

[Tad McClellan]

I was suggesting eval (),

There are _two_ eval()s in Perl, "eval EXPR" and "eval BLOCK".

Which were you suggesting?

(your post has expired from my news server)

not symrefs.

Using symrefs is bad.

Using eval EXPR is even worse.

The usual _good_ solution when you thing you want symrefs is to
chose a better data structure in the first place.

 

[Brian McCauley]

BM> The problem that code using symbolic references is also usually
BM> slightly slower than the equivalent code using a lexically scoped
BM> hash is the main reason not to use symbolic references.

small speed differences should never be the main reason to not use a
perl feature.

Yes, somehow in my typing and revising of the above sentence the
sentiment got negated. It should, of course, have said "not the main
reason". Opps.

--
( )
. _____[oo
.__/ /\@
. l___ /
# ll ll
###LL LL