On Wednesday 22 October 2008 2:31:38 am Mike van Riel wrote: > >> Example destruction order: > >> 3 = database records (ActiveRecord or such) > >> 2 = database connection object > >> 1 = framework objects > >> 0 = objects with unspecified level > > > > Why would you need such thing? > > PHP uses reference-counting and destroys objects as soon, as there are > > no more references to them. Since PHP 5.3, it also detects > > cyclic-references and periodically destroys object-groups which have > > references to each other, but do not have references from external > > context. > > Additionally, AFAIK in an ideal situation a destructor should only > destroy objects which exist during the lifetime of an instance of the > class containing the destructor. > If objects have a greater lifespan (i.e. shared) then they should be > destroyed by other means, like at the end of their lifespan or at the > end of your script.
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. -- Larry Garfield [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
