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] |
Who said anything about making $q a global? It already was. I'm saying he might have wanted it to keep on being a global. When fixing someone else's code, I try to follow the "minimal change" doctrine. If it's a global, leave it a global. Especially since it's proper for this variable to be a global, given how it's used for input, processing and output.
I'm still confused why you say "Lexical variables don't retain values when they go out of scope". It's true, but it's meaningless here. Both lexical variables and localized package variables lose their values at the end of their scope. Both global lexical variables and global package variables have the same scope. Replacing my $q with local our $q would give $q neither a larger scope nor a greater persistance. Do you think otherwise?
| [reply] |