Re: Allowing user to change module variables

[dragonchild]

$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.

[mvaline]

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.

[dragonchild]

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.)

[Ovid]

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.