What _should_ DESTROY do?

dokkeldepper has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: What _should_ DESTROY do? by jettero (Monsignor) on May 11, 2007 at 13:00 UTC
I like perlobj for really detailed info on the objects and their internals... What should it do? Clean up circular refs and close sockets and things probably? Otherwise there's usually little need. I'd say, find the call to DESTROY in tester.pl (line 0?) and add an `if $obj->can("DESTROY")` or just comment it out. I wonder why they'd call it explicitly, that's atypical by itself. -Paul	[reply] [d/l]
Re: What _should_ DESTROY do? by dk (Chaplain) on May 11, 2007 at 12:49 UTC
DESTROY is a special name of the destructor method for blessed objects and tied variables. It is called automatically when an object is no longer referenced, and is about to be destroyed. See more f.ex. in perltoot Destructors As to what should it do, that depends on the nature of the class, f.ex. if constructor opens a connection, then destructor should close it, same OO stuff as elsewhere.	[reply]
Re: What _should_ DESTROY do? by leocharre (Priest) on May 11, 2007 at 13:18 UTC
I've got this oo module, it may open a database handle with autocommit off- It may or may not open other handles.. I use DESTROY to check if the handles are open, if they need to be committed, and then if the connection needs to be.. let's say- 'disconnected'. I'm no authority- but my loose understanding is DESTROY is the last thing that will happen in that code as long as your module is alive- like with BEGIN{} you know it's the first thing that will happen. That can be of use to you.	[reply]
Re: What _should_ DESTROY do? by Joost (Canon) on May 11, 2007 at 23:20 UTC
The guiding principle is simple: DESTROY should clean up whatever doesn't get cleaned up automatically when the object is deleted. 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. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re: What _should_ DESTROY do? by Anonymous Monk on May 11, 2007 at 13:28 UTC
Once I wrote a library which loaded a dataset into memory at new(). Then while the library was used by the mastering script, this data was altered. Then, when the master was done, the library wrote back the modified data via the magic DESTORY() sub - effectively implementing a simple SQL transaction behaviour. -Just as an example... But if this is what DESTROY _should_ do.... Well, it's what it _can_ do.	[reply]


P is for Practical
	PerlMonks