Indirect addressing problem

[tel2]

Dearly beloved Monks, lend me your brains...please.

Instead of coding this kind of thing:

$mailbox   = 'inbox';
$subscribe = 'yes';
$country   = 'NZ';

$sel_mailbox{$mailbox}     = 'test';
$sel_subscribe{$subscribe} = 'test';
$sel_country{$country}     = 'test';

I was wanting to do recode the last group of lines more elegantly, with something like this:

for (qw(mailbox subscribe country))
{ ${"$sel_$_{$$_}"} = 'test' }  # <= Not working!!!

But I can see that's not working, because there's nothing in $sel_mailbox(inbox).
I think there are various ways to code this with references, but the above style what I usually use, but alas, I've failed.

Please guide me back to the straight and narrow.

Thanks.
tel2

[1nickt]

First, you shouldn't do that. See Why it's stupid to 'use a variable as a variable name'.

Second, why don't you have 'mailbox', 'subscribe' and 'country' as keys in a single hash? No need to have multiple hashes.

#!/usr/bin/perl
use strict;
use warnings;
use feature qw/ say /;
use Data::Dumper;

my @values = ('inbox', 'yes', 'NZ');
my %data;
$data{ $_ } = shift @values for qw/ mailbox subscribe country /;
say Dumper \%data;

__END__

Output:

[nick:~/monks]$ perl 1140269.pl
$VAR1 = {
          'subscribe' => 'yes',
          'country' => 'NZ',
          'mailbox' => 'inbox'
        };

Update: Or, if you have multiple records you can just put the code above in another loop. Below I make the hashref keys from a counter; perhaps you have user names or something that could be the keys.

#!/usr/bin/perl
use strict;
use warnings;
use feature qw/ say /;
use Data::Dumper;
$Data::Dumper::Sortkeys = 1;

my @records = ( [ 'inbox',  'yes', 'NZ' ],
                [ 'inbox',  'no',  'UK' ],
                [ 'outbox', 'yes', 'UK' ] );
my $href;
my $index = 0;

foreach my $record ( @records ) { 
  ++$index;
  $href->{ $index }->{ $_ } = shift @{ $record } for qw/ mailbox subsc
+ribe country /;
}

say Dumper $href;

__END__

Output:

[nick:~/monks]$ perl 1140269.pl
$VAR1 = {
          '1' => {
                   'country' => 'NZ',
                   'mailbox' => 'inbox',
                   'subscribe' => 'yes'
                 },
          '2' => {
                   'country' => 'UK',
                   'mailbox' => 'inbox',
                   'subscribe' => 'no'
                 },
          '3' => {
                   'country' => 'UK',
                   'mailbox' => 'outbox',
                   'subscribe' => 'yes'
                 }
        };

[tel2]

Thanks very much for that, 1nickt.

tel2

[parv]

"Straight and narrow" does not go with the solution that you are apparently looking for: eval & symbolic reference.

[tel2]

Hi parv,
Do you mean that I:
- should not be using eval & symbolic references. If so, in what way am I doing that now?
- should be using eval & symbolic references instead?

Thanks.
tel2

[Anonymous Monk]

 # <= Not working!!! is the part where you tried symbolic references... but the way its written it could only possibly work by using eval

It is not a good solution, since you could simply use regular reference

http://perl.plover.com/varvarname.html explains how to do it, whats wrong with it, the code is fundamentally unsafe, like smoking in bed while juggling flaming chainsaws in bed

[parv]

Below is what already had been stated in other words; feel free to ignore ...

"Straight and narrow" solution had already been mentioned.

My point was that if one reads up on eval function and what, how, why (not) of symbolic reference, then one would|should be able to generate a solution (for "var-var" usage).

[sundialsvc4]

Please code “this kind of thing,” instead of “elegantly.”   Please.

Why?   Because, at a glance, I can see and understand what the first example is doing, and, even there comes a time where one of the many cases is slightly different, I can still easily maintain it and be entirely certain that the changed code still works.   In your “elegant” example, every single one of these cases has been coupled to one another.   It is no longer possible to see “at a glance” what the code is intended to do, nor to be certain that in all cases it actually does it.

Generally speaking, don’t try to economize on source-code statements, especially not at the expense of expressiveness and maintainability as has been done here.