Front page | perl.perl6.internals |
Postings from February 2001
On Wed, Feb 14, 2001 at 02:10:59PM -0300, Branden wrote: > > Dan Sugalski wrote: > > > Plus there's nothing stopping you from having $obj->DESTROY in your own > > code, though it may be inadvisable. > > It is (mainly) inadvisable because: > 1. GC will call DESTROY when it collects the memory, so DESTROY would get > called twice, which is VERY BAD. *blink* It is? Why? I grant you it isn't the clearest way of programming, but "VERY BAD"? > 2. If I call DESTROY on an object, it would still be a (valid) object after > the call, so that if I call some other method, it will succeed. But that > shouldn't happen, since the object was DESTROYed, right? Eh, you don't understand DESTROY. DESTROY doesn't destroy an object. Perl, the language, does not have the concept of destroying objects. DESTROY is just a call back from perl, the binary, that everyone is done with the object, and it's about to go away. DESTROY might be called around the same time its memory is being reclaimed, but from a language perspective, all this memory dealing is non-existant. DESTROY is a language thing, garbage collection an implementation detail of the run-time, purely necessary because of the limited physical model of the abstract machine Perl is supposed to run on. Their perceived relation is merely a coincidence. Even if you have a bucket load of memory and there was a way of telling Perl not to bother with garbage collection, DESTROY should still be called. Being able to separate DESTROY and garbage collection is a feature. ;-) AbigailThread Previous | Thread Next