Where is the reference being stored after it is returned from the function? If you are writing a module that is used by others and they are reporting the errors, then you have a worse problem. You can note in the documentation for your module that they should not put your objects into global variables, but that may not be acceptable.
You might want to post a working example that reproduces the problem.
My Win32::TieRegistry has this problem. I was lucky in that the consequences of it are relatively minor once I got rid of the ugly warning that it was producing (some Registry keys won't get "auto unloaded" in rare cases, but this feature isn't used much anyway). So I didn't really solve the problem.
To really solve it you could require perl 5.6 for your module and do something similar to what chromatic suggested. You create "weak back links" that run in the opposite direction to your references and have the subordinate object's destructor tell the parent object to "clean up" (if the parent hasn't already been DESTROYed). And the parent object has to be able to handle either being told to "clean up" first (if the subordinate gets DESTROYed first) or just being told to DESTROY (if the parent gets DESTROYed first).
I'd rather have a "fix" for Perl because working around this can get really, really ugly.
- tye (but my friends call me "Tye")In reply to (tye)Re3: How can I call other objects from my object during DESTROY
by tye
in thread How can I call other objects from my object during DESTROY
by amackey
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |