On Sat, Dec 17, 2011 at 07:00:03AM -0800, Father Chrysostomos via RT wrote: > It looks as though the latter will be the only recourse. Due to the > unfortunate practice, sometimes encouraged on the beginners' list, of > not explicitly closing file handles, my first suggestion, which would > make for a cleaner implementation, would prevent the last-read file > handle from going out of scope and result in breakage (of already-broken > code; Perl already makes no guarantee as to when things will be freed) > and bug reports.
I believe that there is a guarantee for objects, else all the code that assumes that destructors fire at the end of scope would be wrong. [Without this, you can't do "Resource Acquisition Is Initialisation"] Whilst file handles happen to be objects internally, I don't think that there is any documented guarantee in Perl 5. However, I think it's strongly implied that they are freed promptly, and I *think* that it is explicit in Perl 6 that file handles are released at end of *scope*. [Note the check for Perl 6 is end of scope, not end of statement. Cc: to perl6-language@perl.org so that they can correct me if I'm wrong. The perl 5 implementation effectively offers end of statement, as that's when temporaries are freed] However, I agree that failing to explicitly close is bad and to be discouraged. On writing, well, heck, if you don't check you clearly don't care for correctness, so you might as well skip writing any data. Even for reading, failing to check close means you can't be sure if your input was truncated due to an error. Nicholas Clark
