in reply to when is destroy function called
perldoc perlobj contains a definitive discussion both of destructors and of Perl’s garbage collector. I think that the best way of thinking of both constructors and destructors is that they are “initialization” and “de-initialization” subroutines, respectively. Of the two, destructors are less commonly used because they are less commonly required: if there are no “unusual” storage-reference situations that might confuse the garbage collection algorithm, and no external resources to clean up, you often don’t need one.
As a rule of thumb, if you do something in the object’s constructor that is peculiar to that particular object instance and that has to be un-done, then you need to worry about defining a destructor. But if you simply allocated a big data-structure that’s associated with the object, no worries, because the reference-count of all those things will also go to zero when the object itself does. (Any exceptions to that rule will of course require an appropriate destructor.)
One thing that I can definitely say from very painful experience is this: that you must never leave an ambiguous situation behind when your destructor completes. If you “close” a socket, say, then immediately obliterate all memory of it (undef). This is doubly true if you are indulging in fancy-pants designs involving subclasses of any sort. Look carefully at the entire constructor and destructor sequences as your application grows.