That would be correct for an explicit close(). If you let the variable fall off the end of a block, now you're depending on destruction. Destruction in Perl isn't 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] |
Everything I've seen says that destruction in Perl is timely. Destruction occurs as soon as the value's ref count reaches zero. Do you have any documentation to contradict that?
This is in contrast with Java, where garbage collection is not as predictable.
Update: The only documentation bit I've found is in perlref:
Hard references are smart--they keep track of reference counts for you, automatically freeing the thing referred to when its reference count goes to zero.
And it goes on to say
If that thing happens to be an object, the object is destructed.
There's no mention of a delay or of it being deferred. Although it doesn't say explicitly say "immediately", I'm still convinced it is because my belief is based on much more than that one statement.
| [reply] |
Ah. I have found my misremembering. Calling of DESTROY is neither timely nor ordered. Destruction in Perl is timely for lexicals. But, I can't find anything about destruction of localized variables. I would figure that the recovery of the hidden value is timely. But, that doesn't imply that the destruction of the covering value is timely.
I, of course, would love to hear from TimToady, chromatic, or some other guts person. And, frankly, being able to depend on timely destruction would be nice.
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] |
