in reply to Object destruction notification

If the class can be cleanly sub-classed, then you can write a sub-class that allows you to put in hooks at the DESTROY level, before calling $self->SUPER::DESTROY for the "real" destruction. Given that you are only keeping hold of a weak reference, that may be your best bet.

Alternately, if you have developmental control over the class in question, you could develop a super-class with the functionality built in to the DESTROY method, and inherit from that in the main class. That requires writing the target class to either have no built-in destructor, or to make sure to call the super-class destructor. But it also means that you can use the interface (to use the Java terminology :-) with other classes, as well.

--rjray

Replies are listed 'Best First'.
Re: Re: Object destruction notification
by rjray (Chaplain) on Jun 26, 2002 at 06:09 UTC

    I realized upon re-reading this, that you aren't the party responsible for allocating the object (or rather, at this point in the application logic, that knowledge seems to be abstracted away). That makes for a more complex problem, in which case I would probably go the same route you already have. To my knowledge, the only externally-predictable event upon object destruction is the calling of the DESTROY method (if it exists) within that class/package. There isn't (that I know of) a more universal hook point at which you can monitor general object disposal, simply for the sake of catching the few that you care about.

    --rjray

[reply]

In Section Seekers of Perl Wisdom