A number of people have suggested to "not put my objects into global variables" or to "use my()". Where am I putting Special::Object into a global variable? My module returns a blessed hashref, which itself contains (a reference to) another object. While someone seemed to claim that my case wouldn't happen, I most certainly have code in which it does (i.e. when object A's DESTROY is called, object B has already been DESTROY'ed and thus is no longer available to call methods on).

Thanks for clearing up the confusion.

-Aaron

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")

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

I think what isn't clear is what you are doing with the blessed hashref to your object itself. To wit, if your object (the one your original post referred to) were an Xyz, then into what kind of variable are you putting the return from Xyz::new()?

    my $xyz = new Xyz();
[download]

Or,

   $XYZ = new xyz();     # where $XYZ is a package global
[download]

If you are using the latter (for example in a test harness program), you might want to test the former to see if it exhibits the same behavior you originally asked about.