But having a separate clean_up() method would work exactly the same way. Calling it would release the lock. But then, I'd want to make certain it wasn't called again (from DESTROY), if/when the object is really reclaimed, since the lock would have already been released, making it unsafe.

So I'd still need to either add a pre-destruct flag and check it in every method, as suggested, or use my hack of reblessing to a null class.

In the general case, I agree with you, of course. If you want to provide a clean-up method through your interface, then certainly don't call it DESTROY. But in this specific case, I'm really trying to fake destruction for an interface that relies on normal destruction, but which is currently borken due to my dangling references. And so in this case, I still don't see the win.

I understand the magic and am bending it to my will :-)

mla,
please forgive my naive example but, i think iburrell and hossman are referring to something like below, where the actual lock is your pre-desctruct flag...



sub clean_up
{
    my $self = shift;
    if ( $self->{Lock} )
    {
        #
        #    the code to release the lock
        #

        $self->{Lock} = 0;
    }
}

sub DESTROY
{
    my $self = shift;
    $self->clean_up();
}
[download]

So I'd still need to either add a pre-destruct flag and check it in every method, as suggested, or use my hack of reblessing to a null class.

I think you may have missed the point of diotalevi's code. The DESTROY method checks the pre-destruct flag itself, and bails if it's been set, so there's no need for you to check the flag in every method.

cheers,

J

I think you missed the point of doing the check in the other methods. I briefly thought about zeroing the contents of the object but decided not to for simplicity in this case. There's general utility in preventing other methods which might expect the object to still work from actually working. But if that happens then something is seriously wrong so its ok to throw a fatal error.