That makes sense, which would imply that the behaviour of __PACKAGE__ is correct, but surely the code would output Point 2: B 6 5 (ie $main::var incremented, not $B::var).
Also perldoc -f do, implies an equivalence to eval `cat stat.pl`, although it does then say that 'do FILENAME' cannot see lexicals in the enclosing scope. This is one reason why I was using do instead of eval. Is there some way to have this behaviour with eval so that I can get around the scoping of package, but still hide lexical variables?
| [reply]
[d/l]
[select] |
Quite a while ago I recall a thread in which it was noted that some Perl constructs results in a case where there isn't just a single "current package" (I searched but wasn't able to find it and have run out of time for now).
There are several different ways in which the "current package" can be felt. What __PACKAGE__ returns, how $x is interpretted (if there is no lexical $x in scope), where sub foo puts the subroutine, etc.
I think you've discovered this same problem. The outer package should either "leak" in or it should be reset to "main", but some constructs manage to only reset some of the "current package" items (when it should be either "all" or "none", not "some").
So, I think it is simply a bug in Perl, though a minor one.
| [reply]
[d/l]
[select] |