Re^2: symbolic references

thanks for your prompt reply.
i was able to get the following to work :

my @vars = ( \$varA, ) # symbol table entry

$$f = $tmp; # change the table entry only

@vars = ( $varA, ) # now print the variables
i guess i follow your hash usage. it just seems redundant to this naive user.
thanks again for your help

Comment on Re^2: symbolic references

Replies are listed 'Best First'.
Re^3: symbolic references by dragonchild (Archbishop) on Sep 27, 2005 at 19:48 UTC
i guess i follow your hash usage. it just seems redundant to this naive user. It's redundant only if you intend to run your code once, then delete it. If that is not the situation, then it most definitely is not redundant. What the hash does is increase readability. Anytime you increase readability in code that you don't intend on deleting immediately, that is a win-win. The first win comes when you are writing the code, because it reduces the chance for bugs. The second win is when you're modifying the code, because it reduces the chance for bugs. Remember - computers only understand 1's and 0's. Programming languages aren't meant for computers - they're meant for humans. Every feature in a programming language is for a human to use, not a computer. So, if there's a feature that can reduce bugs, you are a fool to not use it. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]

Replies are listed 'Best First'.

Re^3: symbolic references
by dragonchild (Archbishop) on Sep 27, 2005 at 19:48 UTC

i guess i follow your hash usage. it just seems redundant to this naive user.

It's redundant only if you intend to run your code once, then delete it. If that is not the situation, then it most definitely is not redundant. What the hash does is increase readability. Anytime you increase readability in code that you don't intend on deleting immediately, that is a win-win. The first win comes when you are writing the code, because it reduces the chance for bugs. The second win is when you're modifying the code, because it reduces the chance for bugs.

Remember - computers only understand 1's and 0's. Programming languages aren't meant for computers - they're meant for humans. Every feature in a programming language is for a human to use, not a computer. So, if there's a feature that can reduce bugs, you are a fool to not use it.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

[reply]