Re: Variable scalar creation.

Definitely NOT recommended, but if you turn off strict, you can accomplish what you want by:

my $arraycnt = 0;
$$_ = $values[$arraycnt++] for @names;
[download]

However, I would strongly urge you to use hashes - both for safety, and convenience.

Update: Also, please read Why it's stupid to `use a variable as a variable name'

Another warning - there is no guarantee that the name you are attempting to create from the content of @names is a valid perl variable-identifier. You may get strange run-time errors.

..."I don't know what the facts are but somebody's certainly going to sit down with him and find out what he knows that they may not know, and make sure he knows what they know that he may not know, and that's a good thing. I think it's a very constructive exchange," --Donald Rumsfeld

Comment on Re: Variable scalar creation. Download Code

Replies are listed 'Best First'.
Re^2: Variable scalar creation. by snappybo (Initiate) on Feb 13, 2005 at 08:29 UTC
Sure i can, i'm just trying to create a set of variables that match the database field names filled with the relevant data (a good 800 or so fields). As i said i understand it could be better to use hashes and so on, but in this case the variables built from @names aren't variables at all, because they are fieldnames from a database that don't change.. Which allows me to use the one reference in all the applications that access this particular database.. And the above worked perfectly.. Thanks..	[reply]
Re^3: Variable scalar creation. by davido (Cardinal) on Feb 13, 2005 at 16:28 UTC
And how exactly is using the fieldnames from a database to dynamically create scalar variable names an improvement over using a hash to hold the fieldnames and their respective values? I'm really curious. With the hash method, you get one hash, easily transportable by hard reference, and easily manipulated. With the symbolic ref method, you get variable names that are created in the global symbol table hash, which you must continue to use via soft reference throughout the remainder of the script unless your script both dynamically creates the variable names and hard codes them. ...if it's the latter, and you're hard coding the names at later points in the script, may as well hard code them from the beginning instead of creating them on the fly. The fact is that there are few good uses of symbolic references. An exception is the exporting of global variables between packages... but even this should be handled with care and often via the well-proven Exporter module. Many languages don't even allow the use of soft references, and yet they still get along just fine without them. Dave	[reply]