Stephane Richard wrote:
> But the fact of the matter remains, I need
> lists of data, an array or a linked list, whichever, and I need that list
> available throughout the rest of the packages somehow.
> Now instead of stopping your comment at telling me that this design is
> bad, that global variables bring global famine, let me assure you that list I
> am talking about is NOT a food shopping list :-). Why dont you detail
> yourself and bring me the other alternatives and possible solutions. If you know
> of a way to obtain this availability without the use of global variables then
> please, by all means, do let me know so that I may do this the right way.
I don't know exactly what you're trying to do, so I can't design it for
you. Are the lists accessed by subprograms provided by the packages?
Then perhaps they should be parameters to those subprograms.
Do they record state between calls to subprograms? The simplest example
of this is a random-number generator, in which a variables in a package
body stores the state of the generator and is updated by the operations
provided by the package. In this case, the variable is global to the
operations, but private to the package.
A more complicated version of this has the lists accessed during the
sequence of statements of the package body. In either case, your
packages are part of some larger abstraction. Perhaps they should be
sub-packages of another package, with the lists declared in the package
body. Perhaps they should be child packages, with the lists declared in
the private part of the parent.
I hope this gives you some hints about how to proceed. I have never
encountered a situation in which global variables were necessary. I
would be surprised if they were necessary in your case.
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail