a global filehandle is not necessary - a lexical declared in the module will do exactly the same job
My original argument was (intended to be) that global file handles and file-scope lexical file handles are equivalent, and the choice between them is a neutral matter of style.
this seems to be an argument for lexical filehandles rather than global ones
This comes back to a matter of style — for some programmers it may be such an argument, for others ALLCAPS tokens may be in a different "five, plus or minus two" from regular variables.
I think the usage of globals can be avoided 99.9% of the time
I agree that the use of globals generally should be minimized, but I consider file-scope lexicals (especially in the main script) a "sneaky" form of global variable. My concern is opposing unthinking "never use globals!" policies that then result in using file-scope lexicals in exactly the same way as globals — except that lexicals are harder to inspect.
On a side note, a file-scope lexical can possibly have wider scope than a global if the same file defines multiple packages. Each global is contained in its package, but the lexical will persist across package statements to the end of the file.
I disagree with it being harder to debug; issues arising from incorrectly used globals are IMHO much more annoying to debug
File-scope lexicals effectively are globals, except that they are harder to inspect in the debugger. The "even harder to debug" remark was in reference to a "never use globals!" approach where the callback is wrapped in a closure that also carries references to lexicals in the block that will use it. The effect is global variables that are not actually in the symbol table, and (as far as I know) are almost impossible to debug because there is no way to look inside a closure.
In reply to Re^8: Summing numbers in a file
by jcb
in thread Summing numbers in a file
by pvfki
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |