DESTROY redefined?

Ovid on 2006-06-28T14:31:52

Today's annoyance was writing this bit of code for tearing down my test database:

no warnings 'redefine';
*DESTROY = sub {
    my $self = shift;
    my $dbh  = $self->dbh;
    # boring stuff
    $dbh->disconnect;
};

That's in my _initialize method for the constructor. That eliminated my "subroutine DESTROY redefined at ..." warning, but for the life of me, I can't figure out how this method was getting redefined. This seems to to be a common problem with database related modules, but I'm only seeing the error reports, not the resolution. I hate hitting a problem that should be simple yet I nonetheless get stumped on. Brute forcing a solution makes me feel icky.

Of course, the garbage collection bugs also mean that the stored database handle might be garbage collected when I get to this point. I'll have to fix that, too, if it hits me (usually done with an annoying lexical variable hanging around in my otherwise clean code). Has this ever been fixed?

Update: How embarrassing. I remembered how to solve this:

use Sub::Identify ':all';
main::diag(stash_name(\&DESTROY));

Guess what? That DESTROY came from my own Class::BuildMethods. Of course, I documented that it exports a DESTROY unless specifically told not to, so it's my own fault :)

---

Have DESTROY call something else...

dagolden on 2006-06-28T15:06:26

Class::InsideOut and other inside-out class builders provide DESTROY but have it call a user-defined DEMOLISH (if that exists) to support that kind of teardown.

Re:Have DESTROY call something else...

Ovid on 2006-06-28T15:18:29

I provide a similar facility. My DESTROY method now looks like this:

sub DESTROY {
    my $self = shift;
    # wreak havoc
    Class::BuildMethods->destroy($self);
}

I might make silly mistakes, but not that silly :)