Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:10840 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 52014 invoked by uid 1010); 29 Jun 2004 07:29:55 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 51989 invoked from network); 29 Jun 2004 07:29:55 -0000 Received: from unknown (HELO stack.fission.org.uk) (195.82.120.217) by pb1.pair.com with SMTP; 29 Jun 2004 07:29:55 -0000 Received: from cpc4-oxfd3-3-0-cust191.oxfd.cable.ntl.com ([213.107.70.191] helo=[192.168.10.254]) by stack.fission.org.uk with esmtp (Exim 3.36 #1 (Debian)) id 1BfD1n-0006eD-00; Tue, 29 Jun 2004 08:27:39 +0100 To: Florian Schaper , internals@lists.php.net In-Reply-To: <000b01c45d02$95eab040$9f00a8c0@silverbox> References: <000b01c45d02$95eab040$9f00a8c0@silverbox> Content-Type: text/plain Message-ID: <1088494196.2185.23.camel@mesa> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 29 Jun 2004 08:29:56 +0100 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] __Destruct() functionality From: gareth@fission.org.uk (Gareth Ardron) On Mon, 2004-06-28 at 12:25, Florian Schaper wrote: > > __destruct will get executed during request shutdown after the > > communication has been shutdown. The only way to be able to write > > from within __destruct is to deinitialize it at the end of the > > script and therefore before the request is being finished. To > > do so you can use 'unset($object);' > But then again why call destruct on the objects after the external > modules have been shut down? This heavily confuses people and I > see no apparent reason to do so (then again I'm not deep into the PHP > internal structure)? I find it highly attractive to be able to save a > "session"-object via my destructor / close DB connections - you name > it. > > zend_objects_store_call_destructors(&EG(objects_store) TSRMLS_CC); > before php_call_shutdown_functions(); etc. This is where I was heading as well in the original mail :) There's a huge amount of scope within __destruct() to be able to pull off a load of tricks really nice and cleanly - even if that's just closing db connectections or extra logging, it's still really nice. while I'm happy to unset($object), this is rather an ugly way round what could be quite an elegant feature. What I found really confusing though, was the documentation on this subject. The docs state that __destruct() is called with no parameters when the last reference to the object is removed from memory. It's not immediatly apparent that this happens during shutdown; I'd have guessed at just before. This meant I spent half an hour changing things round to see if I could work out just how it was working. Really annoying thing being that if a class has a private variable which is itself an object of another class, and you do something like this inside the __destruct() function: $this->logger->logEvent("leaving class"); then not only doesn't it work, but you don't get any errors either. However, this would give you an error: $this->logEvent("leaving class"); At the very least, could somebody poke the docs a bit to reflect this a bit better? (though I'd prefer the way destruct is called to be changed ;-) )