Closures (closures) take advantage of lexical scope (scope) to mediate access to semi-private variables. Even named functions can take advantage of lexical bindings:
The encapsulation of functions to toggle the safety allows all three functions to share state without exposing the lexical variable directly to external code. This idiom works well for cases where external code should be able to change internal state, but it's clunkier when only one function needs to manage that state.
Suppose every hundredth person at your ice cream parlor gets free sprinkles:
This approach works, but creating a new lexical scope for a single function introduces more accidental complexity than is necessary. The state builtin allows you to declare a lexically scoped variable with a value that persists between invocations:
You must enable this feature explicitly by using a module such as Modern::Perl, the feature pragma (pragmas), or requiring a specific version of Perl of 5.10 or newer (with use 5.010; or use 5.012;, for example).
state also works within anonymous functions:
... though there are few obvious benefits to this approach.
Perl 5.10 deprecated a technique from previous versions of Perl by which you could effectively emulate state. A named function could close over its previous lexical scope by abusing a quirk of implementation. Using a postfix conditional which evaluates to false with a my declaration avoided reinitializing a lexical variable to undef or its initialized value.
Any use of a postfix conditional expression modifying a lexical variable declaration now produces a deprecation warning. It's too easy to write inadvertently buggy code with this technique; use state instead where available, or a true closure otherwise. Rewrite this idiom when you encounter it:
Hey! The above document had some coding errors, which are explained below:
- Around line 3:
-
A non-empty Z<>