On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote: > I think you just said all about why we shouldn't bother giving objects > deterministic finalization, and I agree with you. If we explicitly want to > free resources (files, database connections), then we explicitly call close. > Otherwise, it will be called when DESTROY is eventually called. No, the question of whether Perl 6 wants deterministic finalization or not is a separate one. If it doesn't have it, we will be losing a very common Perl idiom: { my $fh = IO::File->new("file"); print $fh $data; } It's nice to know that when the above block exits, $fh will be closed. Remember that "closed" doesn't just refer to freeing the resources associated with it -- it also includes flushing buffers and the like. Without deterministic finalization, you will almost always want to write the above to include an explicit $fh->close(). The problem is that you can not only count on $fh's DESTROY being called at the end of the block, you often can't count on it ever happening. Consider the case where the interpreter dies on a signal, for example -- DESTROY methods will quite possibly not be called. I'm not certain that Perl should lose deterministic finalization. On the other hand, I really wish that Perl had a more modern GC scheme, if only so that circular structures could be properly collected. In the end, however, I don't think that any of our opinions will decide this -- either Dan's forthcoming PDD will show how Perl 6 can have its cake and eat it too, or Larry will decide. - DamienThread Previous | Thread Next