It's not that the file is left open per se. Perl (and every other language worth using) doesn't necessarily flush buffers immediately. close() does an explicit flush and destroys the handle. However, if you let the variable fall off the end of the scope, now you're depending on destruction to close the handle (and flush the buffer). Destruction in Perl is neither ordered nor timely.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
It's not that the file is left open per se. It's not that the file is left open per se. Perl ... doesn't necessarily flush buffers immediately. ... However, if you let the variable fall off the end of the scope, now you're depending on destruction to close the handle (and flush the buffer).
I think there is a contradiction in this. Of course
I/O is usually flushed, but you if I understand you right, you consider it possible that the file is not open anymore (because the handle falls out of scope), but that the buffer is flushed only if the handle is destroyed (i.e. later). But this makes no sense, IMO: You can't flush a buffer to a file, if the file is already closed.
This leaves us with two possibilities: Either Perl does a proper close on the file, if the handle goes out of scope (which means that the buffer would be flushed), or that it does not close the file after the handle goes out of scope (and leaves it up to the destructor of the handle to flush the buffer and close the file, i.e. likely at program end).
The first alternative would make sense. The second alternative would mean that at the end of the block, the file is still happily open. At least in the cases I tried, it behaved as if alternative 1 would be implemented, but I was wondering whether or not this is something I can rely to...
--
Ronald Fischer <ynnor@mm.st>
| [reply] |
