in reply to Re^2: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?
in thread what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?

What i read here in that link.. ominous.. Yeah im getting the feeling that i might as well use global variables then singleton objects.

so, i still have these "master hashes" that i'd like to have my whole program access, want to add new modules as time goes by and no matter where the code is, i want to know that %::Garage will hold all the cars- and i have to do that by declaring our %Garage in main.

am i going to coding hell?

Please keep in mind im a poop virgin.

i'm feeling like i've really missed something here with scoping and protecting symbol tables and even why- im thinking maybe i need to .. take a vacation. or play with static electricity close to the box fan.

where can i read about ways around poop? about protecting the symbol table, why... any specific suggestions?

  • Comment on Re^3: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?
  • Select or Download Code

Replies are listed 'Best First'.
Re^4: what is a propper way to make a chunk of data accessible to all my packages for retrieval and modification ?
by Aristotle (Chancellor) on Mar 03, 2006 at 20:20 UTC

    I’d suggest writing configuration class and having the constructors of all your application classes take an instance of it.

    It depends on what you need to do with the data, though. Not all globals are evil.

    Makeshifts last the longest.

[reply]
      So you're suggesting a singleton after all ? ;)
[reply]

        No, I’m suggesting a class that can be instantiated as many times as you want, like any other class, which is exactly what a singleton is not, then passing it around everywhere. If you have wildly unrelated things you’d be putting into this class if you just translated your current scheme 1:1, then instead, create different classes for each thematically grouped set of things, and pass them around as needed.

        Ideally you should be able to run multiple concurrent instances of any of your classes with a different configuration each.

        The goal is to avoid creating dependencies on the configuration objects such that you’ll end up having to be careful about the order in which you call methods due to side effects – that’s exactly the problem created by globals.

        Makeshifts last the longest.

[reply]

In Section Seekers of Perl Wisdom