in reply to Re^4: How not to use "our"?
in thread How not to use "our"?

's better to export a collective hash (reference) or individual variables (as suggested by JavaFan)?

Personally, I wouldn't export either.

As I attempted to show above, I'd use individual package (our) variables, and use them via fully qualified references:

package MyConfig;

our $one = ...;
our $two = ...;

[download]
use MyConfig;

...
if( $x <= $MyConfig::one ) {
...

[download]

All the variable are nicely contained within the package stash (symbol table hash); warnings are issued for typos; and where they come from is clearly defined. And by not importing them, you avoid namespace clashes.

If they are truly constants, then I use constant and avail myself of the optimisations that brings.

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.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^6: How not to use "our"?
by Anonymous Monk on Nov 30, 2010 at 14:32 UTC

    Ah, I understand now. Many thanks :)

    With your approach - declaring variables with "our" - would it lead to problems with mod_perl? I've never used mod_perl before, but I read that you can't have globals when using mod_perl.

    Suppose I export the hashed variables (as in my approach), would that cause problems in a mod_perl environment?

[reply]
      Whether you can have, or cannot have, package variables is unrelated to whether the package variables are scalars or hashes, or whether they are exported or not.

      Note also that if mod_perl means you cannot have globals, it would mean you cannot have Perl. Certain global variables always exist.

      The issue with mod_perl is that modules get only compiled "once" (well, typically, once in the life time of an Apache child), and not each time the program is run. This means "globals" may not get (re)initialized. But that is not the same as package variables!. File scoped lexicals and sub-bounded state variables won't get (re)initialized either. And package variables that get initialized in your mod_perl program do get initialized.

      The mod_perl issue all has to do when certain code is run - not whether variables are package variables or lexicals.

[reply]

        Thanks for above, JavaFan!

        I'm trying to grasp the concept before I use mod_perl, so please bear with me if my questions sounded silly.

        I'm trying to make sense of 'The issue with mod_perl is that modules get only compiled "once"'. Let's say I've a variable (my $score) in a module that stores the score of a user, say, playing a game. When another user comes online, or for that matter, when several users appear, will the variable correctly store the value for each of the user when the script (that calls the said module) is run?

[reply]

In Section Seekers of Perl Wisdom