Hash keys to scalar variable conversion.

D

Derek Basch

If I have a hash that has many keys/values is there a way to make the
keys into scalars named the same as the key values?

for instance:

$hash{ 'user_name' } = 'bob';

turns into:

$user_name = 'bob'

Thanks,
Derek basch
 
A

A. Sinan Unur

If I have a hash that has many keys/values is there a way to make the
keys into scalars named the same as the key values?

for instance:

$hash{ 'user_name' } = 'bob';

turns into:

$user_name = 'bob'

This is a FAQ.

perldoc -q "variable name"

Found in C:\opt\Perl\lib\pod\perlfaq7.pod
How can I use a variable as a variable name?
Beginners often think they want to have a variable contain the name
of a variable.

In short, this is a bad idea.

Sinan
--
A. Sinan Unur <[email protected]>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
 
P

Paul Lalli

Derek said:
If I have a hash that has many keys/values is there a way to make the
keys into scalars named the same as the key values?

for instance:

$hash{ 'user_name' } = 'bob';

turns into:

$user_name = 'bob'

Why on earth do you think you want to do this?

See also:
perldoc -q "variable name"

Paul Lalli
 
J

jdamon

Hi Derek,

Since the advent of multi-dimensional datastructures with Perl 5, the
Perl community has frowned upon such an action. It used to be the case
that this is how you would construct a large multi-level object, by
doing something like
$a = "b";
$$a = 22;

print $b . "\n";

would print "22";

With that being said, coupled with the fact that in Perl there should
be many ways to do things ( and I would never be the first to judge
someone wanting to try something out ) , you can do the following:


${"main::user_name"} = "bob";

so, it could be done with

foreach ( keys %hash ) {
${"main::$_"} = $hash{$_};
}


This is a way to get around problems when you "use strict" which
would prevent you from using the first soluition.

Hope this helps,

-Jimi
 
A

A. Sinan Unur

Since the advent of multi-dimensional datastructures with Perl 5, the
Perl community has frowned upon such an action.

What action? Please quote properly when you reply. Please read the posting
guidelines for this group.

<snip discussion of symrefs>

It is just harmful to teach bad habits to inexperienced programmers.

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

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

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

Sinan

--
A. Sinan Unur <[email protected]>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
 
J

jdamon

Dude, stop being a tool.

jeez, I don't have to quote what is common wisdom and written in both
Programming Perl and the Perl Cookbook.

Get a life
 
U

Uri Guttman

jc> Dude, stop being a tool.
jc> jeez, I don't have to quote what is common wisdom and written in both
jc> Programming Perl and the Perl Cookbook.

then why did you actually show how to use symrefs if you also advocate
not using them? two regulars admonished the OP for such a poor idea and
then you go ahead and tell him how to do it. do you think he will listen
to the others and figure out a better design remove this concept from
his head? or will he just take the easy route and use your answer and go
down the highway to hellish code?

jc> Get a life

get a brane.

uri
 
D

Derek Basch

Good lord people. Calm the hell down. It's just programming.

I figured out on my own that it was a bad idea and am just using hash
references now.

Thanks for all the help everyone!
 
A

A. Sinan Unur

U

Uri Guttman

DB> Good lord people. Calm the hell down. It's just programming.
DB> I figured out on my own that it was a bad idea and am just using hash
DB> references now.

when you have been coding for 30 years and don't see any need to head
off bad coding advice, then i will listen to you and calm down. many of
the world's problems are from bad coding (or bad people in general).

uri
 
J

jdamon

Uri said:
when you have been coding for 30 years and don't see any need to head
off bad coding advice, then i will listen to you and calm down. many of
the world's problems are from bad coding (or bad people in general).

It's too bad that you don't know the key phrase of Perl which is
"there is more than one way to do it".

I prefaced my comment with "this is not the advised way to do it" which
I am sure that was understood by Derek.

What is annoying is when people proclaim to have perfect sight with
regard to being the judge of what is and is not good code.

The truth is, someone is going to think your code is "bad" no matter
what you do with it. They might even just make this assessment based
on the fact that you might choose to code in Perl over some other
language.

We should all be engaged with programming because we find it fun.
There will always be bad code, and you shouldn't think that you are
impervious to doing so. Programming is about learning how to overcome
the next challenge that is thrown at you whether it be because of a
poor implementation or a ground up difficult project. Perl is no
exception on that matter. The key differences I find that make Perl
worth coding in ( i.e. the reason I find Perl the most fun language )
are a. there IS more than one way to do it and b. sometimes its cool
to find out that a wierd little thing you dreamed up *actually* works.

( Who would have honestly thought something like @hash{keys
%otherhash} would work ? )

The fact that people are so quick to crush creativity is quite
obnoxious and is antithetical to the main message of Perl.

So , I think it is the duty of experienced programmers to give advice
to new comers yet not quash their desire to explore the beautiful
eccentricities of the language.
 
U

Uri Guttman

jc> It's too bad that you don't know the key phrase of Perl which is
jc> "there is more than one way to do it".

jc> ( Who would have honestly thought something like @hash{keys
jc> %otherhash} would work ? )

someone who rtfm'ed and learned about slices.

jc> The fact that people are so quick to crush creativity is quite
jc> obnoxious and is antithetical to the main message of Perl.

well, you handle all the bad coding ideas that come in here. i will
handle the good one. seems like a fair split to me.

jc> So , I think it is the duty of experienced programmers to give advice
jc> to new comers yet not quash their desire to explore the beautiful
jc> eccentricities of the language.

IIRC, synrefs was at the heart of this and no decent coder would call
that a beautiful eccentricity of the language. if you think it is, then
your perl skills are way below what is needed to teach it. symrefs are a
powerful tool and can be very deadly and should be used as a last
resort. the rule is very simple, use symrefs when you want to mung the
symbol table itself and don't use them to mung data structures. the
symbol table is just another data structure but it is not as safe as
real structures and it is slower. there is absolutely no reason to use
it for data munging so timtowtdi doesn't apply here.

uri
 
A

A. Sinan Unur

It's too bad that you don't know the key phrase of Perl which is
"there is more than one way to do it".

That is not a good reason to choose the suboptimal way.

Sinan
 
D

David H. Adler

That is not a good reason to choose the suboptimal way.

I can't remember the exact quote, but Larry Wall once said that just
because there's more than one way to do it, that doesn't mean all those
ways are *good* ways.

dha
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top