Creating a hash with inferred key names?

[mrstevegross]

I've got a few variables that I'm using to create a hash: $foo, $bar,
and $baz. The keys for those values are the same as the variable
names: 'foo', 'bar', and 'baz'. Currently, I create the hash like so:

my $hsh_ref = { 'foo' => $foo, 'bar' => $bar, 'baz' => $baz };

Given that the key names are identical to the variable names, is there
a way to create the hash so that I don't have to enter the key names
explicitly? Something like (in pseudocode):

my $hsh_ref = { use_var_names_as_keys $foo, $bar, $baz };

Any ideas?

Thanks,
--Steve

 

[Uri Guttman]

m> I've got a few variables that I'm using to create a hash: $foo, $bar,
m> and $baz. The keys for those values are the same as the variable
m> names: 'foo', 'bar', and 'baz'. Currently, I create the hash like so:

m> my $hsh_ref = { 'foo' => $foo, 'bar' => $bar, 'baz' => $baz };

m> Given that the key names are identical to the variable names, is there
m> a way to create the hash so that I don't have to enter the key names
m> explicitly? Something like (in pseudocode):

m> my $hsh_ref = { use_var_names_as_keys $foo, $bar, $baz };

why did you keep those values in scalar vars to begin with? if you want
them in a hash now, what were you doing before with them that didn't
need a hash? there is no direct way to do what you want other than evil
stuff i won't even mention. so i suspect you have a poor design decision
from earlier which is pushing you into this corner. so backup, explain
the bigger problem and likely a much cleaner solution will show itself.

uri

 

[mrstevegross]

why did you keep those values in scalar vars to begin with? if you want

them in a hash now, what were you doing before with them that didn't
need a hash? there is no direct way to do what you want other than evil
stuff i won't even mention. so i suspect you have a poor design decision
from earlier which is pushing you into this corner. so backup, explain
the bigger problem and likely a much cleaner solution will show itself.

Wow, dude, that's a bit harsh. The reason why is that I need to first
verify that all of them are calculable before I put them in the hash.
The hash by definition has all the values defined, so I first need to
figure them out before I put them into the hash.

--Steve

 

[Jürgen Exner]

I've got a few variables that I'm using to create a hash: $foo, $bar,
and $baz. The keys for those values are the same as the variable
names: 'foo', 'bar', and 'baz'. Currently, I create the hash like so:

my $hsh_ref = { 'foo' => $foo, 'bar' => $bar, 'baz' => $baz };

Given that the key names are identical to the variable names, is there
a way to create the hash so that I don't have to enter the key names
explicitly? Something like (in pseudocode):

my $hsh_ref = { use_var_names_as_keys $foo, $bar, $baz };

Directly: no.
Opposite direction, i.e. given the names construct the variables, is
known as symbolic references and condemned here regularly (see "perldoc
-q variable name").

Indirectly: perldoc -f eval

jue

 

[Willem]

mrstevegross wrote:
) Wow, dude, that's a bit harsh. The reason why is that I need to first
) verify that all of them are calculable before I put them in the hash.
) The hash by definition has all the values defined, so I first need to
) figure them out before I put them into the hash.

So use a second hash. Or delete the non-calculable ones from the hash.
Or toss the whole calculable thing in a map operation. Or ...


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[mrstevegross]

Directly: no.

Opposite direction, i.e. given the names construct the variables, is
known as symbolic references and condemned here regularly (see "perldoc
-q variable name").

Indirectly: perldoc -f eval

jue

Ok, good to know. I figured this was probably a long shot.

Thanks,
--Steve

 

[Uri Guttman]

m> Wow, dude, that's a bit harsh. The reason why is that I need to first
m> verify that all of them are calculable before I put them in the hash.
m> The hash by definition has all the values defined, so I first need to
m> figure them out before I put them into the hash.

it isn't as harsh as using those evil techniques which is what you are
asking for (even if you didn't know it). so i am smacking you to stop
you from burning your hand on the stove. get it?

you can calculate them and store them directly in the hash if you
want. there may be no reason for the scalar vars.

uri

 

[Jürgen Exner]

Wow, dude, that's a bit harsh. The reason why is that I need to first
verify that all of them are calculable before I put them in the hash.
The hash by definition has all the values defined, so I first need to
figure them out before I put them into the hash.

???
I thing there is some basic misunderstanding her. What do you mean by
"The hash [...] has all the values defined"? There is no problem
defining additional hash elements at any point in the program. Just do
%myhash{newelem} = "whatever my heart desires";
to incrementally build up your hash.

I cannot imagine a situation where $foo and $hash{foo} would be any
different. There may be some odd situations like auto-vivication which
by nature of the issue is for hashes only, but otherwise they are
identical.

jue

 

[Uri Guttman]

m> Ok, good to know. I figured this was probably a long shot.

and i said the same thing without naming the evil techniques for your
safety.

uri

 

[mrstevegross]

I thing there is some basic misunderstanding her. What do you mean by
"The hash [...] has all the values defined"? There is no problem
defining additional hash elements at any point in the program. Just do
        %myhash{newelem} = "whatever my heart desires";
to incrementally build up your hash.

I cannot imagine a situation where $foo and $hash{foo} would be any
different. There may be some odd situations like auto-vivication which
by nature of the issue is for hashes only, but otherwise they are
identical.

By "defined", I meant "has valid values". That is, first I go through
a bunch of steps to figure out if I can indeed come up with valid
values for foo, bar, and baz. IFF all three can be calculated, then I
create the hash to store them. Else, the hash doesn't get defined at
all.

--Steve

 

[Todd]

this may help:

perl -MData:umper -e '$foo=1, $bar=2, $baz=3; $h{$_} = $$_ for qw/foo bar baz/; print Dumper \%h'

$VAR1 = {
'bar' => 2,
'baz' => 3,
'foo' => 1
};

 

[J. Gleixner]

Wow, dude, that's a bit harsh. The reason why is that I need to first
verify that all of them are calculable before I put them in the hash.
The hash by definition has all the values defined, so I first need to
figure them out before I put them into the hash.

--Steve

Possibly what Uri, who you neglected to cite in your reply, was
suggesting is that instead of setting $foo to something, set
$hash{ 'foo' } to something. Use a hash from the beginning,
instead of a scalar.

That way you could then use a hash slice, to create your $hsh_ref,
consisting of only acceptable keys.

 

[Uri Guttman]

T> this may help:

NO IT DOESN'T!

we all said in this thread not to use symbolic refs as they are evil and
not wanted here. the solution lies with a different design.

uri

 

[Jürgen Exner]

I thing there is some basic misunderstanding her. What do you mean by
"The hash [...] has all the values defined"? There is no problem
defining additional hash elements at any point in the program. Just do
        %myhash{newelem} = "whatever my heart desires";
to incrementally build up your hash.

I cannot imagine a situation where $foo and $hash{foo} would be any
different. There may be some odd situations like auto-vivication which
by nature of the issue is for hashes only, but otherwise they are
identical.

By "defined", I meant "has valid values". That is, first I go through
a bunch of steps to figure out if I can indeed come up with valid
values for foo, bar, and baz. IFF all three can be calculated, then I
create the hash to store them. Else, the hash doesn't get defined at
all.

Well, what is blocking you from using $myhash{foo} instead of $foo (and
same for the others) to check if you can come up with valid values for
all of them?

jue

 

[Todd]

we all said in this thread not to use symbolic refs as they are evil and

not wanted here. the solution lies with a different design.

Yes, they are evil. but Perl is attractive due to its evilness, more
natural way using map:

perl -MData:umper -e '$foo=1, $bar=2; %h = map {$_ => $$_ } qw/foo bar baz/; print Dumper \%h'

$VAR1 = {
'bar' => 2,
'baz' => undef,
'foo' => 1
};

 

[Uri Guttman]

T> Yes, they are evil. but Perl is attractive due to its evilness, more
T> natural way using map:

map isn't the issue in your code. it is the symref that is evil and map
can't hide that. your code isn't strict clean and useless in the case
the OP asked about. if he has the keys already, why would he want the
vals in scalar vars first? either use a hash to begin with or do the
proper assignment when needed. symrefs have no benefits here. the rule
is use symrefs when you are munging the symbol table. don't use symrefs
for general data structure munging which is what your code does.

uri

 

[smallpond]

I thing there is some basic misunderstanding her. What do you mean by
"The hash [...] has all the values defined"? There is no problem
defining additional hash elements at any point in the program. Just do
%myhash{newelem} = "whatever my heart desires";
to incrementally build up your hash.

I cannot imagine a situation where $foo and $hash{foo} would be any
different. There may be some odd situations like auto-vivication which
by nature of the issue is for hashes only, but otherwise they are
identical.

By "defined", I meant "has valid values". That is, first I go through
a bunch of steps to figure out if I can indeed come up with valid
values for foo, bar, and baz. IFF all three can be calculated, then I
create the hash to store them. Else, the hash doesn't get defined at
all.

You say this as though there is a reason not to just start with the
hash.
Perhaps you worry that there is some cost or difficulty in defining
a hash vs 3 scalars.

Dont.

 

[smallpond]

T> Yes, they are evil. but Perl is attractive due to its evilness, more
T> natural way using map:


map isn't the issue in your code. it is the symref that is evil and map
can't hide that. your code isn't strict clean and useless in the case
the OP asked about. if he has the keys already, why would he want the
vals in scalar vars first? either use a hash to begin with or do the
proper assignment when needed. symrefs have no benefits here. the rule
is use symrefs when you are munging the symbol table. don't use symrefs
for general data structure munging which is what your code does.

Zen perl:

The perl beginner had a problem.
He said "Aha! I can solve this with symrefs."
Now he has two problems.

 

[Uri Guttman]

s> Zen perl:

s> The perl beginner had a problem.
s> He said "Aha! I can solve this with symrefs."
s> Now he has two problems.

eggselent!!

uri