This seems like a parse error, but it's hard to say that the current behavior isn't intentional. Here are a few similar snippets, and how they deparse with -MO=Deparse,x9:
use strict; use warnings; my $pic = 1; my $v = {R3R3_1_IF => 100}; print "Hello world. $v->{R3R3_$pic\_IF}\n";
The output with perl -MO=Deparse,x9 mytest.pl:
Backslash found where operator expected at mytest.pl line 9, near "$pi +c\" (Missing operator before \?) Bareword "_IF" not allowed while "strict subs" in use at mytest.pl lin +e 9. mytest.pl had compilation errors. use warnings; use strict; my $pic = 1; my $v = {'R3R3_1_IF', 100}; print "Hello world. $$v{$pic->R3R3_(\'_IF')}\n";
If you attempt to disambiguate using curly braces it still fails:
use strict; use warnings; my $pic = 1; my $v = {R3R3_1_IF => 100}; print "Hello world. $v->{R3R3_${pic}_IF}\n";
The output...
Bareword found where operator expected at mytest.pl line 9, near "${pi +c}_IF" (Missing operator before _IF?) Bareword "_IF" not allowed while "strict subs" in use at mytest.pl lin +e 9. mytest.pl had compilation errors. use warnings; use strict; my $pic = 1; my $v = {'R3R3_1_IF', 100}; print "Hello world. $$v{$pic->R3R3_('_IF')}\n";
In both cases the interesting deparse to me is $pic->R3R3_('_IF'), and the explanation appears to be that the parser seems to feel this is a fine time to see the construct as indirect object notation.
Dave
In reply to Re: variable inside hash key
by davido
in thread variable inside hash key
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |