in reply to Allowing user to change module variables

$OUILookup::oui_location = "blah"; will work if the variable wasn't declared with my.

Of course, it's better to have a function called set_ouilocation() to do it for you. Just a thought.

  • Comment on Re: Allowing user to change module variables

Replies are listed 'Best First'.
Re: Re: Allowing user to change module variables
by mvaline (Friar) on Jul 19, 2001 at 00:00 UTC
    Ah, of course I should have such a function. I'll do that.

    With regard to the first solution... would our be the correct scoping keyword to declare my variable with it? I can't just declare it or use strict barks at me.

      strict complains if it has either no scoping or a scoping of local. my gives you nice, neat lexical scoping. our gives you a funky lexically-scoped global-type-thingy which I'm not fully conversant with, but works relatively well.

      If you're going to create a function to get/set this variable, do something like:

      my $var = 0; sub get_var { return $var; } sub set_var { my ($new_val) = @_; # Do some checks on $new_val here. $var = $new_val; return $var; }

      The reason you have it scoped with my is to keep it protected as much as possible from accidental clobbering.

      (Of course, you could just put yourself into that namespace, but that's just being silly.)

        If you're going to have subs to return and set values, I like to combine them:

        my $oui_lookup; sub oui_lookup { my $newval = shift; # validation, if necessary if ( defined $newval ) { $oui_lookup = $newval; } $oui_lookup; }

        If it's exported to your main namespace, you can use it as follows:

        my $old_lookup = oui_lookup(); my $new_lookup = oui_lookup( $some_new_val );

        Admittedly, having separate subs can be cleaner, so some may object to my way of doing it.

        Cheers,
        Ovid

        Vote for paco!

        Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.