Well, technically, yes, you missed the demise of local, but only because we renamed it to temp and made it completely orthogonal to storage class declarations. You can temporize any variable, and it will restore itself at the end of the current lexical scope. You can also conditionally temporize a variable using let, and it resets at the block end only if the block fails. But these are operations on existing variables.
Even in Perl 5, local never declares a variable,
but merely temporarily changes the value of an existing global.
And to reiterate, state variables are not globals. They're persistent lexicals. You can temporize them, but then you can temporize my variables as well. You can even temporize attribute accessors and not worry about whether the accessor represents a real attribute or is a wrapper around something else:
temp $handle.autoflush = 1;
| [reply]
[d/l]
[select] |
Okay. The analogy with C statics was flawed. That makes sense.
I should really have referred to our rather than local, but I think your explaination suffices.
What happens if I do:
sub bar {
state $foo;
...
my $code = sub qux {
state $foo;
};
...
}
Is this illegal?
Or do the two refer to the same thing?
Or does the inner $foo hide the outer $foo for the duration of that scope?
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
| [reply]
[d/l] |
If it's illegal, it's because you took the address of a named declaration, not because of the state declarations. But ignoring the "qux" (and the entire question of whether that should be legal) your use of state variables would certainly be legal. The inner $foo hides the outer $foo just as a "my" variable would. And every time you clone the inner closure you'll get a new copy of the inner state variable, and it will initialize itself the first time that clone is called.
It implies the existence of some kind of persistent lexical pad, which is a certain amount of work for the implementation, but we really didn't see much benefit in duplicating the functionality of globals, and a lot of benefit in having a kind of "my" that doesn't reinitialize the second time through.
| [reply] |
