how to use the value of a scalar as a name for another scalar

[azzazzello]

suppose I have

$entry = <>;
$one = ($entry == '2') ? "two"; "other";
$two = "bam";
$other = "kaboom";

print (the variable that matches the value of $one)

If 2 is typed, I want to have $one somehow interpolated to "two" and then do something like ${two}. If anything else is typed, I want it to interpolate to "other" and print out the value of $other. But I can't seem to nest them...Help?

 

[varakal]

Use
print ${$one}
with out having 'use strict'

 

[azzazzello]

ok, I see...but why doesn't it work if I stick a my in front of my variables? Then it's just blank

 

[varakal]

It's because only package variables are visible to symbolic references (that's what we are using here). Lexical variables (declared with my()) aren't in a symbol table, and thus are invisible to this mechanism.

 

[azzazzello]

ah! ok, makes sense. One more question...suppose I need to do this with packages instead of variables. Here's what happens

use vars qw($test $func);
$test = "func";
$func = "Trig";
print "Printing *".${$test}."*\n" #ok, this works;
use Math::${test}; 

# Above line gives Bad name after :: at interpoltest.pl;

 

[PaulTEG]

eval might be the cookie here?
--Paul

cigless ...

 

[azzazzello]

well...it's not a matter of error checking, if that's what you mean. I want to select a package to load dynamically, based on a value of the $func variable

 

[varakal]

I think 'use' would not work because it requires and imports the modules at compile time. Symbolic references would do at run time, so is the error.

I tried with 'require' and it didnt work. Though require would not import modules at compile time, it might be because 'require' checks the availability of modules (in @INC) at compile time, which again are not available because of symbolic references.

I am not sure about what I said above, so dont take it for granted.

 

[azzazzello]

well, I did this instead of use

print Math::${test}->blah();

which should have produced a compile time error. Instead it gave me a BAD NAME error again. methods are most certainly not compile-time checked. It's crying about the syntax

 

[azzazzello]

ack, I meant to say that it should have produced a runtime error

 

[ishnid]

Incidentally, the use of soft references is generally considered to be a Bad Thing. In most situations, using a hash will turn out to be a superior solution (its benefits in avoiding awkward debugging more than makes up for the additional typing). There's a good article to explain why here.

OffTopic - @Paul - you just *knew* I'd post that, didn't you??

 

[PaulTEG]

I was going to post it, but I thought of it as thunder stealing ;-)

@azzazzello, I was considering building up the string for the use statement, and then eval the use statement

As ishnid says soft references are a bad thing, but I still use GOTO ;-) If it's the only horse for the course


cigless ...

 

[justice41]

It's possible to use require for a dynamically called module, but it requires a modification in the way the module is referred to.

two different ways:
without importing, needs symbolic (soft) references

my $test = "Trig";

require "Math/$test.pm";
print "Math::${test}::tan"->(1);

or following 'strict':

my $test = "Trig";

require "Math/$test.pm";
## or instead
# eval "require Math::$test";
"Math::$test"->import();

print tan(1),"\n";

I admit that I don't understand fully the subtlety between "Math::${test}::tan"->(1), which doen't work under 'strict' and "Math::$test"->import(), which does.

regards,

jaa

 

[1DMF]

Hey PaulTEG,

Is there really a GOTO command in PERL

 

[PaulTEG]

Here you go

Don't go mad y'all ;-)
--Paul

cigless ...

 

[TrojanWarBlade]

In all the years I've been writing Perl, indeed all the years I've been developing (over 20), I've never used a "GOTO" yet.
But I've had to deal with the consequences of others using it many times.
When you write code, do spare a thought for the poor guy that has to deal with the consequences. Please.





Trojan.

 

[PaulTEG]

There are times, given, very few.

I used to maintain spaghetti COBOL code, so I know exactly what you mean.

I did say "Don't go mad".

next, last, die are effectively gotos of a sort at any rate, because they wouldn't pop values onto the stack to return to, but that's splitting hairs :-D

cigless ...

 

[stevexff]

Must admit it's not one of my favourites. COBOL used to have

GO TO label1 label2 label3 label4 DEPENDING ON variable.

which is kind of a case statement combined with a bunch of GOTOs, which was a nightmare, especially as if variable was out of range it didn't do anything at all.

I kind of went off the idea of GOTO after that...

 

[1DMF]

ohh that looks ugly

The goto-&NAME form is highly magical, and substitutes a call to the named subroutine for the currently running subroutine.

Some things are best left unknown Paul, my ignorance of the command 'goto' was certainly bliss, and I shall erase all knowledge of its existence.

If I come across code where it has been used, I will refuse to maintain it and re-write the script, I might be old, but I've moved on from programming my ZX Spectrum & VIC 20. Thank God!

 

[PaulTEG]

No worries, there's a goto in every language I've ever used ... I think, but I've mostly avoided its use ;-)

cigless ...