Re^5: File-scoped lexicals and eval scope?

I called it a trick because it exploits undefined behaviour in the language. perl 5.10, 5.12 or some future version may or may not preserve the same behaviour, so it seems to me bad practice to promulgate it's use.

As I'm sure you know, perldoc perlsyn states:

NOTE: The behaviour of a "my" statement modified with a statement modi‐ fier conditional or loop construct (e.g. "my $x if ...") is undefined. The value of the "my" variable may be "undef", any previously assigned value, or possibly anything else. Don’t rely on it. Future versions of perl might do something different from the version of perl you try it out on. Here be dragons.

Comment on Re^5: File-scoped lexicals and eval scope?

Replies are listed 'Best First'.
Re^6: File-scoped lexicals and eval scope? by ysth (Canon) on Nov 12, 2007 at 01:10 UTC
Ah. I wasn't suggesting `my $value if 0;`, nor would that work to make the sub close over the outer $value. I was suggesting `$value if 0;`, to incorporate a reference to the outer $value into the sub, while avoiding the "Useless use of a variable in void context" warning you'd get from a bare `$value;`.	[reply] [d/l] [select]
Re^7: File-scoped lexicals and eval scope? by jbert (Priest) on Nov 12, 2007 at 08:08 UTC
Ah....sorry. Stupid of me. That does raise an interesting question as to what code a perl optimiser would be allowed to remove. You'd really like the optimiser to be able to nuke code like this: `while (tight_loop) { write_to_log("Some msg involving $somevar") if REALLY_HEAVY_DEBUG; some_more_code(); }` [download] if the constant evaluated to 0. I guess if `$somevar` was relevant to the debugging then it would be closed over anyway, but that is a bit too subtle.	[reply] [d/l] [select]
Re^8: File-scoped lexicals and eval scope? by ysth (Canon) on Nov 12, 2007 at 08:52 UTC
The optimiser does do that, leaving only an empty statement, but at a later point than the closure is established.	[reply]