Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:41340
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ead.fiocruz.br from 157.86.152.50 cause and error)
Message-ID: <49005CB9.1070500@ead.fiocruz.br>
Date: Thu, 23 Oct 2008 09:15:05 -0200
User-Agent: Thunderbird 1.5.0.14ubu (X11/20080925)
MIME-Version: 1.0
To: Larry Garfield <larry@garfieldtech.com>
CC: internals@lists.php.net
References: <A8.C0.10341.9DB7EF84@pb1.pair.com> <cd5680a20810212300q322c2255y2a71ed753c791449@mail.gmail.com> <48FED6DA.2090400@naenius.com> <200810222123.58206.larry@garfieldtech.com>
In-Reply-To: <200810222123.58206.larry@garfieldtech.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Destructor Order
From: diogo@ead.fiocruz.br (=?UTF-8?B?RGlvZ28gR2FsdsOjbw==?=)

"The destructor method will be called as soon as all references to a
particular object are removed or when the object is explicitly destroyed
or in any order in shutdown sequence."

As far as I understand it if your active record references the PDO
instance (say $this->conn) your object gets destroyed before the
connection object.

Perhaps it's a better approach then introducing destruction order for 
global or singleton problems.


wbr,
Diogo

Larry Garfield wrote:
> On Wednesday 22 October 2008 2:31:38 am Mike van Riel wrote:
> 
> 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.
>