Sure it does. The $q created here is persistent and is part of the symbol table. It will get reset to the value it had before the local was applied to it at the end of the file, but it's still a global variable. Are you really saying you don't think passing variables to subs is a cleaner solution? | [reply] |
If you think my variables are freed, you're wrong. Neither the variable (on the pad) nor the SV assigned to it are freed at the end of the function.
Are you really saying you don't think passing variables to subs is a cleaner solution?
I agree that the number of global variables should be limited, and I find few reason to use them. However, the author thought it acceptable and/or desirable for $q to be a global variable, so I just pointed out a way to make that possible.
| [reply]
[d/l]
[select] |
I know that the actually memory is not freed, but that's an implementation detail. The behavior is not like a global. Lexical variables don't retain values when they go out of scope.
I don't think the author was trying to make $q a global. I think the author was trying to fix a closure problem, and "local our" is not as good a solution to that problem as passing the variables to the subs.
| [reply] |