> Bareword filehandles are essentially global
Sorry for nitpicking but they are package variables not full globals.
Conflicts can be avoided with proper use of package directives.
Special variables are real globals, they are available everywhere but always belong to main:: package (IIRC)
| [reply]
[d/l] |
| [reply] |
| [reply] |
| [reply] |
A review of PBP which praises Damian's rationale without quoting it, alas
If you are really keen you might be able to read at least part of the rationale by searching via google books,
I just did that and here is some of Damian's rationale:
... using a bareword as a file handle causes Perl to store the corresponding input stream descriptor in the symbol table of the current package ... and if that symbol has already been used as a filehandle anywhere else in the same package, executing this open statement will close the previous file handle and replace it with the newly opened one ... bareword file handles are even more unreliable if there happens to be a subroutine of the same name currently in scope ...
For completeness, from Perl Best Practices
here are all Perl Best Practices that mention bareword or filehandle:
- 45. Don't use barewords.
- 125. Don't use bareword filehandles.
- 126. Use indirect filehandles.
- 127. If you have to use a package filehandle, localize it first.
- 130. Close filehandles explicitly, and as soon as possible.
- 133. Slurp a filehandle with a do block for purity.
- 136. Always put filehandles in braces within any print statement.
- 246. Don't tie variables or filehandles.
| [reply] |
As an example, one of my worst debugging sessions involved open's scope. Imagine you have a generic open_file() function in a script. The function uses a bareword FH, because whoever wrote it wasn't thinking about scope, they were just making sure a file was "open" (kinda related to the counterpoint you mentioned, that person might have learned enough to get by but not yet realize all the implications of what they were doing). Sometimes, deep in the code, you might open *another* file while processing the first one, leading to some bewildering action at a distince bugs... | [reply] |
> because whoever wrote it wasn't thinking about scope,
FWIW you can localize a FH inside the function's scope, but this implies some glob syntax IIRC.
I think local *FH but ...
- I'd need to look it up
- it'll localize all other vars with the same symbol, like $FH too
- it's a dynamic runtime scope not a lexical, ie don't call another sub from inside which doesn't localize the same symbol before using it
Not that beginner friendly
| [reply]
[d/l] |
