On Mon, 2005-12-05 at 20:44 +0100, Torsten Foertsch wrote: > I would not say that. DESTROY is reliable in that it does exactly what it > should. It is called when the last reference to an object goes away.
The issue is that things don't always go out of scope when people think they do. We've all seen this with Apache::Session problems and I've also seen it with Class::DBI using weak references to keep an "object index." People are often surprised to discover they have done something that prevents an object from going out of scope. It's just a side effect of Perl's complexity. > See above, it was not my goal to make an application better than it is. If it > was developed with global handles, well ... so be it. This is different from Apache::DBI though. With Apache::DBI, the rollback will get called as long as something called connect() for that handle during the request. With your module, if disconnect() and DESTROY don't happen (because something died, but the handle didn't go out of scope for some reason), no rollback will happen. It probably seems like more of an issue to me than to you because you trust DESTROY to happen and I don't. > You mean $dbh->{$PRIVATE} is wrong? Maybe because $dbh->{$PRIVATE}||=... > would > not work? That has been avoided in the code. What else is wrong with that? In general, it's not a good idea to access the internals of someone else's class implementation. DBI does allow it, but has certain rules about namespaces. See the section "General Interface Rules & Caveats" in the DBI docs. There are also other ways to store private attributes without touching the object itself, like making your own container object to hold the handle and the metadata. - Perrin