in reply to Re: explicitly calling destructor
in thread explicitly calling destructor

What the rebless accomplishes though, is that any attempt to interact with the object after the explicit call to DESTROY() will be safely routed to the null class. I agree, your proposed solution would work, but in that case I'd really want to modify all the methods to check _PRE_DESTROY to be safe (I suppose I could do that with a subclass and an AUTOLOAD that performs that check).

I'd really like to just force the ref count of the object to zero and null out all references that exist to it, regardless of where they are. But it seems like the rebless is the next best thing (i.e., I may not be able to find all the references right now, but I can make them all point into nothingness).

And yes, I intend to find the dangling references. This most definitely is a hack. I suspect it's an unintended closure rather than a circular reference.

Thanks for responding.

Replies are listed 'Best First'.
Re: Re: Re: explicitly calling destructor
by diotalevi (Canon) on May 15, 2003 at 23:43 UTC

    You can preemptively decrement the refcount to the variable but that just means that the dangling reference will now have a pointer into memory that doesn't belong to it anymore. I guess you could have an EvilHack package which just throws errors when any method in it is called. Maybe you'd find out where its being referenced from that way.

    For some creative package names consider Blessing into bitstrings. ;-)</code>