in reply to Are global variables "bad"?

Saying "Global variables are bad!", is like saying "Drugs are bad!". Used wrongly they can be harmful. Used correctly they are a powerful good.

And remember, entries in the symbol table are just global variables. So, if you substitute a 'singleton' instance, for a global variable, you are just substituting (at least) one global variable for another. And making your code far more complicated to boot.

If you need global access to something, use a global variable. It's cleaner, clearer and safer.

Like 'democracies' in which only one party is allowed, classes in which only one instance is allowed, are just a sham, putting a politically acceptable face on the truth.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: Are global variables "bad"?
by Argel (Prior) on Apr 22, 2009 at 01:07 UTC
    If you need global access to something, use a global variable. It's cleaner, clearer and safer.
    In fact, if anything, the OP could probably benefit more from Dominus's excellent and now freely available book Higher Order Perl. A lot of the concepts in there like dispatch tables, etc. are more likely to lead to a better program than a crash course on OO will.

    Elda Taluta; Sarks Sark; Ark Arks
[reply]
      A lot of the concepts in there like dispatch tables, etc. are more likely to lead to a better program than a crash course on OO will.

      I couldn't agree more. (Though with a caveat!)

      Dominus covers some really useful techniques in HOP. And does so in a very clear and logical style. He is to be congratulated on the clarity of both his writing style and the way the topics covered, fit to together, and follow on from each other. I hope he made (is making) some money from it. (Directly or indirectly.)

      The caveat is to only use those technques where they fit your application's requirements. As with OO, don't try and force-fit your application to the techniques. The downfall of all programming methodologies is when they get adopted wholesale to the exclusion of all else. Some algorithms and requirements are a good fit for OO; other less so. Sometimes FP techniques are the way; other times not. Sometimes, good old-fashioned procedural techniques are all that is required and the clearest solution.

      The trick with all these things is to pick the right tool for the particular job, and avoid the 'I have a hammer' scenario.

      A secondary caveat of the HOP techniques is to bear in mind the cost of Perl 5 function calls. Whilst the HOP techniques work, and the descriptions are clearer than many other treatments of the material, they do tend to rely upon lots of nested functions calls, each of which that does very little--and that exacts a substantial penalty in Perl 5.

      I'd love to see HOP adapted to Perl 6/Parrot, once that pairing starts delivering on its potential. I think that would be something really special.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        HOP is sitting on my desktop in PDF as we speak. I must be psycho, er, psychic since I just downloaded it right before beginning this thread. Great suggestion/advice guys thank you!
[reply]

In Section Seekers of Perl Wisdom