Re^2: Mandatory Symbolic References?

As I understand it, the OP wants the hash entry to be an alias to the legacy $alpha_state variable, so that both see the same value ("I want the hash value $hash{alpha}{state} to always equal $alpha_state."). Or put differently, if either one of them is being changed, the other one automatically holds the changed value as well.

eval only assigns the value the variable holds at the time of the eval. If it changes afterwards, the hash entry will not be updated; nor will changing the hash entry update $alpha_state.

Comment on Re^2: Mandatory Symbolic References? Select or Download Code

Replies are listed 'Best First'.
Re^3: Mandatory Symbolic References? by ELISHEVA (Prior) on Jan 18, 2011 at 21:46 UTC
If that is what he means, I agree with your analysis - my solution does not update nor was it intended to. I took my interpretation from the example he gave where it seemed to me that what he wanted was an easy way to assign a set of regularly named variables into hash keys based on the variable naming conventions. I assumed that the "$alpha_state" value was essentially a constant because that is how the OP presented it - the inherited code assigned it a value. This is a pattern I've seen before - read in data from a CGI stream, populate some variables and never change them, then read the variables later on to either re-present the data or use it as input to some calculation. I just recently analyzed such code in a post Re: This runs WAY too slow. Even though an alias would be more powerful than my solution (being read/write), I don't like creating such alaises unless it is really, really necessary. It makes the program that much harder to maintain and adds to the documentation burden. But only the OP actually knows what he wants, so maybe he/she will tell us?	[reply]

Replies are listed 'Best First'.

Re^3: Mandatory Symbolic References?
by ELISHEVA (Prior) on Jan 18, 2011 at 21:46 UTC

If that is what he means, I agree with your analysis - my solution does not update nor was it intended to.

I took my interpretation from the example he gave where it seemed to me that what he wanted was an easy way to assign a set of regularly named variables into hash keys based on the variable naming conventions. I assumed that the "$alpha_state" value was essentially a constant because that is how the OP presented it - the inherited code assigned it a value. This is a pattern I've seen before - read in data from a CGI stream, populate some variables and never change them, then read the variables later on to either re-present the data or use it as input to some calculation. I just recently analyzed such code in a post Re: This runs WAY too slow.

Even though an alias would be more powerful than my solution (being read/write), I don't like creating such alaises unless it is really, really necessary. It makes the program that much harder to maintain and adds to the documentation burden.

But only the OP actually knows what he wants, so maybe he/she will tell us?

[reply]