First suggestion: use warnings;
As for using a global hash... It's got the same advantages and disadvantages as using any other global variable, really. There are cases where it's a good idea, but there are also cases where something else would do better. It's really hard to say without more information about what you are doing.
| [reply] [d/l] |
Getting a value created in a subroutine to another non-contiguous subroutine without having to pass it to places it does not need to go.
Am I just a poor programmer or is there some practice or technique I am not using that I should?
| [reply] |
Ways to achieve the desired goal:
- Global variables with our
- Make sure the subroutines that require access are all within the scope of the variable in question. In your posted code, this is the case. The my statement precedes your subroutine definitions and all are at the script level. This is what ikegami pointed out below.
- Explicitly pass the variable around. Makes it clear where it get modified, though it can make subroutine intent less clear and clutter code.
- Create an object/module to hold your variable - see perlboot, perltoot, perlobj... Any subroutine that uses the object will be able to access the package variable, though you may consider using getter and setters. Object oriented code is about as bad as bloated code gets, but tends to promote clarity in addition to Carpal_tunnel_syndrome. It also makes it explicit where you intended to interact with the globals, and if you use setters, you can insert breakpoints to easily track down some of those action at a distance bugs.
- Subroutines with closures to act as getter/setters without an explicit object/module. This starts getting risky for maintenance since some folks would consider this "clever".
Which option you choose depends on issues like how far separated the elements that need to access the value are logically, how concerned you are with code clarity, whether this is a one-off, whether this is getting distributed, how big the project is, etc. Just keep in mind that nearly every program has a life cycle that is completely different than you think it will be.
I'm sure this list is incomplete - anyone care to add some TIMTOWTDI? There's also providing the fully qualified package name on every access, but that has no benefit I can see over 1. and has some clear issues.
| [reply] |
You are only getting yourself into as much trouble as any global variable can cause. See, for example, Global_variable. Pretty much the arguments against usually come down to spooky action at a distance bugs which can be a real pain to root out. You can avoid this by always explicitly passing variables around or using an OO model (perlboot) and localizing globals to certain packages to make inheritance more clear. It can make sense in certain circumstances, and there are plenty of magic, global variables in Perl (just start reading perlvar), but you should know what you are getting into before you start using globals. | [reply] |
Note that my %heap_hash; would work just as well in the code you posted.
| [reply] [d/l] |
Do you mean sharing values within the same script or among multiple scripts / modules?
If it is the firs one then the easiest way is to have a global variable, i.e. one declared in the outermost scope, you don't need our to do this, read the docs carefully and you'll see what you really want is my. There are obviously dangers (overwriting etc...) with having global variables, but there are ways round this (for example you can 'lock' hashes ( see Hash::Util ) ).
Alternately you can pass variables between subs as references. There are tutorials in the Monastery to help here.
For true 'sharing' of variables, Super Search and CPAN are your friends! HTH!
Just a something something...
| [reply] |