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. ;-)
Abigail
