Example:
One of the nice things about perl is that object destruction is predictable. Simply put, if an object goes out of scope, or is otherwise unreachable, it gets destroyed before the rest of the code is executed. This also means you can also (ab)use DESTROY to do all kinds of "magical"/intuitive things with relatively few headaches.
Languages like Java only destroy unreachable objects "when they feel like it" - usually when they run out of memory or some other limit is reached. That means that in Java it's a bad idea to rely on object destruction to close filehandles or sockets - you can run out of available file handles or other resources before the objects get destroyed. In perl this kind of usage is fairly common.
The nasty thing about this predictability is that object destruction/garbage collection is done via reference counting. That means that if object a has a reference to object b and vice versa and both objects are otherwise unreachable neither object is deleted.
One way of dealing with this is to make one of the references a weak reference (see Scalar::Util's weaken() function).
Another way is to have a "guardian" object keep reference to both object a and b and at its destruction break the circular references between the objects. DESTROY is typically used for that.
In reply to Re: What _should_ DESTROY do?
by Joost
in thread What _should_ DESTROY do?
by dokkeldepper
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |