in reply to Re: Re: Allowing user to change module variables
in thread Allowing user to change module variables

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;
}

[download]

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

Replies are listed 'Best First'.
(Ovid) Re(4): Allowing user to change module variables
by Ovid (Cardinal) on Jul 19, 2001 at 00:19 UTC

    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;
}

    [download]

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

    [download]

    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.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom