Re^6: Confusion over scope of "my" vars

I'm sure the behaviour is well defined and consistent and well thought and I'm trusting it ... but if you say:

> If the refcount is one at scope exit, the variable is cleared*

aren't you denying the results of the OT? The scope of the sub is left, only the reference of the pad should be left, but the variable isn't cleared?

anyway I remember Advanced Perl Programming having a detailed explanation about pads and refcounts. So if you think you don't have a typo in your last post, don't bother explaining to me, what I can easily look up in detail in my bookshelf ... 8 )

Cheers Rolf

Comment on Re^6: Confusion over scope of "my" vars

Replies are listed 'Best First'.
Re^7: Confusion over scope of "my" vars by ikegami (Patriarch) on Nov 27, 2008 at 02:13 UTC
aren't you denying the results of the OT? That was a description of the normal behaviour. To tie it back to the OP, nothing happens on scope exit if the `my` isn't executed.	[reply] [d/l]
Re^8: Confusion over scope of "my" vars by LanX (Saint) on Nov 27, 2008 at 09:35 UTC
> To tie it back to the OP, nothing happens on scope exit if the my isn't executed. Do you know if this is a well defined feature? Can't see why undefining a var with minimized ref-counter should be restricted to a previous my-init !(?) Cheers Rolf	[reply]
Re^9: Confusion over scope of "my" vars by ikegami (Patriarch) on Nov 27, 2008 at 19:23 UTC
Do you know if this is a well defined feature? We've already convered this. It's documented to be undefined behaviour. Can't see why undefining a var with minimized ref-counter should be restricted to a previous my-init !(?) But you're ok with conditionally declaring variables? Anyway, there are tWo problems with what yousaid: The variables are cleared, not undefined. The string buffer is reused too. It has nothing to do with the assignment ("init"). `my $var if 0;` would be just as problematic. In order to reuse the variable, the function needs a reference to it (so it can find it) and the refcount needs to stay above zero (in order for it to be around to be reused). That means the refcounting mechanism won't help us here. I don't know why they tied it to the execution of `my` rather than the compilation of `my`, but it might have to do with saving opcodes. Or simplfying the compiler. Or maybe it would make subroutine reentry too complicated to do otherwise.	[reply] [d/l] [select]