|
|
|
| No such thing as a small change | |
| PerlMonks |
comment on |
| ( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
|
No, that's not the reason for "not stay shared". The reason is that the cloning procedure has to happen at a specific runtime moment when the lexical var(s) to be cloned are alive; however, an inner named sub inside an outer named sub has no specific runtime moment in which it can grab the var and clone it. Consider the situation if the outer sub is never called at all, but the inner sub is called by the main code: When could cloning occur? There's no opportunity. On the other hand, an anonymous sub is an expression which must be evaluated, and that moment of evaluation is the moment of cloning (if cloning is required).
Your example should be a closure. However, if you find that it isn't, it's possible that the current algorithm for deciding whether a variable is at file scope (and therefore not in need of cloning) may be incorrectly ignoring the do BLOCK and other non-sub scoping structures. So if your code doesn't make a closure when exectued at file scope, you may want to file a bug. PS: The reason vars at file scope don't trigger closure behavior is that such vars are usually global in effect and live as long as the program does; cloning references to them is therefore of no use; it may even have caused a bug with sharing state once, though I'm not really sure, and I don't relish reviewing my old p5p mail for closure bugs.... -- Chip Salzenberg, Free-Floating Agent of Chaos In reply to Re(5): Toggling between two values
by chip
|
|