I believe the "end of your script" part is the problem. Imagine you
have some
object (say, ActiveRecord style) that writes itself to the database
when it's
destroyed if the data has been modified. Now cache that object in a
static
variable somewhere for performance. You're also using PDO, so your
database
connection is a global or singleton instance of the PDO class.
Then your script reaches the end. Does your object get destroyed and
therefore saved to the database before or after the PDO object goes
away? I
don't actually know.
I'm not saying that manual destructor order is the correct way to
deal with
that issue necessarily, but I think that's the sort of use case it's
intended
to address.
If you want to treat a PHP script as a traditional application, you
should be prepared to unset() and keep references of everything
yourself. Relying on the garbage collector for your business logic to
work is just bad design.
I'd personally always explicitly do a ->saveObject in similar
situations as its predictable and quite frankly never found a use for
a destructor other than debugging..
Sounds like a subject that doesn't belong on PHP-DEV in any event.
Evert
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
