Re: Are global variables "bad"?

Globals aren't necessarily bad, but they can make growing your program difficult. Suppose you have three functions that work as a group to parse hash X. All is well and good when you are only loading data from one data set into your HoA.

But suppose you one day want to compare HoA's drawn from two or more data sets? What will you do then? Because your functions expect their data in the one and only global variable you are a bit stuck. The problem isn't unsolvable, but it is going to be ugly. You could:

run the functions as is, copy data from the global; clear the global; and then run them again with the new data set.
refactor your code into objects - each object has its own hash. The functions become methods that operate on the object's hash.

However, if, at the very start, you had defined your data and three functions using an an object, then you would have gotten all the benefits of a global variable and avoided the downsides of global variables should your needs expand.

Best, beth

Comment on Re: Are global variables "bad"?

Replies are listed 'Best First'.
Re^2: Are global variables "bad"? by jpearl (Scribe) on Apr 21, 2009 at 17:32 UTC
Hmm. This is good to know, and the impression I'm getting from all the comments is that its probably going to be a good idea to take a crash course in OO perl. The program isn't super huge (maybe 300 lines) but I keep having ideas for additional functionality I'd like it to have. And this is even before the users get a look at it. Even as it is, one of the main reasons for this question was that I started to realize if I wanted some of my ideas implemented I was going to need to increase the number of global variables, and then how I'd need to change the current logic of the program to handle the added functionality and.... etc. Thank you for the comments, everyone has been extremely helpful.	[reply]
Re^3: Are global variables "bad"? by Your Mother (Archbishop) on Apr 21, 2009 at 17:46 UTC
Don't forget to have fun. If this is a learning project or something just for you, don't worry too much about correctness. Just have a good time and pay attention. If you need to refactor later, that can also be fun and a learning experience. Trying to get something perfect up front can be a bit paralyzing and counterproductive. Treating first stabs as prototypes can dig out the real issues you'll face for a robust final version. There is a great quote in the intro to a chapter of one of the Perl books (which I don't have in front of me). Something along the lines of: It is faster to build a four inch telescope and then a six inch telescope, than it is to build a six inch telescope.	[reply]
Re^4: Are global variables "bad"? by jpearl (Scribe) on Apr 21, 2009 at 18:47 UTC
You're definitely right, I've learned a heck of a lot from writing something only to scratch it all later and redo it. I'm pretty sure that's what this program will end up being. Luckily this particular project, while "work", is more of an exercise for myself with positive repercussions for the others in the group, than it is a heavy production style program. Basically I have time to screw up, and then make it right again ;-) Good advice, Thanks Your_Mother	[reply]
Re^3: Are global variables "bad"? by ig (Vicar) on Apr 22, 2009 at 01:02 UTC
Learning the basics of OO perl isn't hard. While there are esoteric aspects that take longer to learn and understand, the basics are well presented in perlboot, perltoot, perltooc and perlbot, which you can read in a few hours, and there are several articles in Object Oriented Programming which provide an easy introduction to simple objects. With a Java background, I expect you would pick up Perl objects and have a significant return on your investment quite quickly.	[reply]


Clear questions and runnable code get the best and fastest answer
	PerlMonks