in reply to socio-political guidance sought

First of all it would be a major transgression to try to offer your own version of a core module. You don't want to go there. Please believe me on that.

Secondly it would be good if you linked to the email with the patch that you sent to p5p. (There are several publically available websites that mirror that email list.)

That may clarify what you're asking for. It sounds like you want Data::Dumper to not try to dump objects that don't have a Freezer method. If this is really what you're asking for, you will never get it. A lot of people like being able to dump objects by default. If you're asking for something else you'll need to be clearer before anyone will act on it.

As for Class:AutoDB, I just glanced at the documentation. Without testing, it is a safe bet that you have serious bugs if the object winds up being destroyed during global destruction. With Perl 5.8 or better there is a hack that reduces how easily the bugs are hit. See Re (tilly) 1: using DESTROY to DBI disconnect and Re: Destructor Order for two posts where I mention this issue, and suggestions for how to avoid it. (Basically you have to do extra work to be sure that things will get cleaned up in an END block if they survived that long.) So even if you get nothing else out of this thread, you just got a pointer to a likely bug!

Replies are listed 'Best First'.
Re^2: socio-political guidance sought
by Anonymous Monk on Aug 20, 2004 at 18:27 UTC
    The object isn't destroyed at global destruction (though I certainly ran head-first into that issue during the first implementations). When the object is created, the Class::AutoDB::SmartProxy class is unshifted onto its ISA array. SmartProxy handles the object's persistence at its own destruction time (in a DESTROY block).
    This seems to happen reliably, thoough I did implement a cache class for the dual purpose of speeding up in-memory access and acting as a container for flyweights (SmartProxy objects) to be destroyed all at once. Only the first purpose is being exercised since I prefer to have database I/O (during object destruction adn subsequent persistence) handled as needed.
[reply]

In Section Seekers of Perl Wisdom