Re (tilly) 1: Oh Brother.

[tilly]

FWIW this time I agree with zigster.

Perl is a language that allows you to play fast and loose. However it does not free you from the laws of human comprehension. It does not change anything about what is and is not good programming technique. And the sooner you learn that, the sooner you will truly master Perl programming. Allow me to summarize the key points:

1. If you wish to solve small problems, then scripting is acceptable and can be done much faster than real programming.
2. If your problems grow into the realm of real programming tasks, scripting as a style is inherently a bad idea.
3. Perl has not proven or disproven any general principle about good programming technique. It merely sits at an unusual combination of design choices that intentionally does not try to force you to program well.
4. As I have said many times, I do not like working with programmers who have not absorbed these principles.

Please read what you wrote and what zigster replied with carefully. Then read Re (tilly) 6: Ways of commenting subroutines. Then read all three parts of Avoid symbolic references.

Hopefully between those I have convinced you that good Perl programming is first and foremost good programming, and only secondly does it have anything to do with Perl as Perl.

[satchboost]

I have to comment. Using symbolic references of the form $$i is stupid. It's more than stupid. You're creating unknown global variables in your script. If you're a dealing with user input, you should be socked. (Homey don't play dat!)

However, if you use symbolic references of the form ${"$package_name::$i"}, I think you're quite a bit safer. You have made sure that the global namespace is safe, especially as you're in control of $package_name. Why would you do this? Well, there's a way of implementing objects using parallel arrays instead of hashes. In certain cases, where you have a large number of instances of this class and/or you will be creating/destroying them on a regular basis, it's much faster, even with the cost of string interpolations and symbolic references.

To sum up, I don't think symbolic references are necessarily a "Bad Thing"(tm). I would actually say it's that global things are almost always bad and that the default way of creating a symbolic reference is in the global namespace.

[tilly]

If you look through my examples you will find symbolic references being used as well. Turning around a recent discussion between us, this is the same issue as using AUTOLOAD all over. Using it immediately opens you up to all sorts of confusions and possible kinds of grief. But with it you can effectively write a program that writes your code for you - which can accomplish very powerful things. Therefore use it, with caution, wisely, but only where it makes sense.

In other words all rules are there because most of the time they make your life easier. But they have exceptions, and when you arrive at a legitimate exception, you should not fear unnecessarily to break the rule. However if you find yourself often deciding that the rule is to be broken, then you are probably doing something seriously wrong and you are probably mistaken. (Because, after all, most of time the rule is right!)