in reply to Re: (tye)Re: How can I call other objects from my object during DESTROY
in thread How can I call other objects from my object during DESTROY

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")
  • Comment on (tye)Re3: How can I call other objects from my object during DESTROY

Replies are listed 'Best First'.
Re: (tye)Re3: How can I call other objects from my object during DESTROY
by Anonymous Monk on Jul 11, 2001 at 06:05 UTC

    Ahh I understand now. Causing the DESTROY to be called at scope-end rather than global destruction time forces the "correct" order of destruction.

    It turns out that my module has a hybrid OO/functional usage (like CGI.pm); when used in functional mode, it generates/keeps an internal object to work with (which is, of course global with respect to the package, and is GC'ed at exit). As you and others have noted, in fact, I have no problems when I use the module in true OO mode.

    I have (temporarily) solved my problem by checking in my DESTROY whether the secondary objects have been destroyed or not - if they have, then I recreate them afresh before calling the methods I need. Ugly, but functional without requiring the user to run a clean_up() method (a la $dbh->disconnect()) before exiting.

    Thanks (again) for all your (and the other PerlMonks') help!

    -Aaron

      Please also try changing your internal object from a package global to a lexical (my) variable with file scope and see if that fixes the problem even when you use the functional interface.

              - tye (but my friends call me "Tye")