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
