Which is never called outside the context of the same lexical pad. All it does is affect a variable outside of its scope. The key is that it's been assigned to local( $SIG{WARN} ) - the sub disappears when the scope goes away.
It's kinda the opposite of a closure, if you think about it. Instead of a subroutine being called outside the scope of a lexical variable yet still affecting it, you have a variable being used outside of the lexical scope of the subroutine that affected it.
Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.
| [reply]
[d/l] |
I would think that's still a closure. Since it is called outside of the lexical scope of the lexical variable. When a signal is caught, we're in the signal handling part of the perl runtime. That is far, far outside of the lexical scope of $warn. So, Perl_warn_handler() calls the coderef it is given, which affects $warn, which is outside of the scope of Perl_warn_handler(). That, to me, is a closure.
| [reply] |