This is a perfect job for a combination of modules and objects. Usually when there is a lot of data that needs to be shared, it is best to encapulate all of it into a single controller class that generates all the necessary objects, manages relationships between them, launches supplemental scripts as needed and so on.

Your main launch script will then be quite simple. It just takes in command line parameters, parses them and sets up a single root object.

Global variables, in and of themselves are not bad, but a massive number of them, especially in the main namespace often signals a design problem in your code. It suggests that you haven't thought through the relationships between the global variables very carefully.

Are they constants? If so, are you cluttering up the global namespace with constant names and preventing your submodules from using those names for their own purposes? Perhaps it would be wiser to place the variables in a package and declare them as our variables. That way they still can be read by all your programs but you don't clutter up the module namespace.

If they are not constants, do they all work in concert? If so, why aren't they encapsualted in an object? If not, why is the relationship between them and why do you need so many?

There may be good reasons for making that single root object a global variable, especially if you declare the variable as an our variable in a package other than main. For example, many application API's have a single $myApp or $SOME_PACKAGE::approot variable. Any script that needs to interact with the application simply makes calls on the $myApp object.

Are you familiar with perltoot? If you are new to objects and classes in Perl, that might be a good place to start.

I know it's not good a idea to use global variables and global data structures.

It's a bad idea to use global variables and global data structures for local use. But if you want information to be accessible globally, there's nothing wrong with global variables. ("Singleton solution" make use of global variables as well - it's just a global coderef instead of global scalar/array/hash). The alternative is to set up your data locally, and pass references to it to every subroutine that either needs it, or calls (directly or indirectly) a subroutine that needs it.

This node was taken out by the NodeReaper on Dec 23, 2010 at 20:38 UTC
Reason: [Corion]: Reap: Linkspam

You may view the original node and the consideration vote tally.

Sorry, that is what googling for walkthroughs/tutorials is for. Why should we type out a 30 page essay yet again?

If you have honestly tried and have a specific problem, copy the error message and the offending code into a node here (with <code></code> tags around the code) and we can help you out.