Perl Cookbook

Perl CookbookSearch this book
Previous: 10.2. Making Variables Private to a FunctionChapter 10
Subroutines
Next: 10.4. Determining Current Function Name
 

10.3. Creating Persistent Private Variables

Problem

You want a variable to retain its value between calls to a subroutine but not be visible outside that routine. For instance, you'd like your function to keep track of how many times it was called.

Solution

Wrap the function in another block, and declare my variables in that block's scope rather than the function's:

{
    my $variable;
    sub mysub {
        # ... accessing $variable
    }
}

If the variables require initialization, make that block a BEGIN so the variable is guaranteed to be set before the main program starts running:

BEGIN {
    my $variable = 1;                       # initial value
    sub othersub {                          # ... accessing $variable
    }
}

Discussion

Unlike local variables in C or C++, Perl's lexical variables don't necessarily get recycled just because their scope has exited. If something more permanent is still aware of the lexical, it will stick around. In this case, mysub uses $variable, so Perl doesn't reclaim the variable when the block around the definition of mysub ends.

Here's how to write a counter:

{
    my $counter;
    sub next_counter { return ++$counter }
}

Each time next_counter is called, it increments and returns the $counter variable. The first time next_counter is called, $counter is undefined, so it behaves as though it were 0 for the ++. The variable is not part of next_counter's scope, but rather part of the block surrounding it. No code from outside can change $counter except by calling next_counter.

Generally, you should use a BEGIN for the extra scope. Otherwise, you could call the function before its variable were initialized.

BEGIN {
    my $counter = 42;
    sub next_counter { return ++$counter }
    sub prev_counter { return --$counter }
}

This technique creates the Perl equivalent of C's static variables. Actually, it's a little better. Rather than being limited to just one function, both functions share their private variable.

See Also

The section on "Closures" in Chapter 4and on "Package Constructors and Destructors: BEGIN and END" in Chapter 5 of Programming Perl; the section on "Private Variables via my( )" in perlsub (1); the section on "Package Constructors and Destructors" in perlmod (1); Recipe 11.4


Previous: 10.2. Making Variables Private to a FunctionPerl CookbookNext: 10.4. Determining Current Function Name
10.2. Making Variables Private to a FunctionBook Index10.4. Determining Current Function Name