Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:26883 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97583 invoked by uid 1010); 10 Dec 2006 09:58:44 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 97568 invoked from network); 10 Dec 2006 09:58:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Dec 2006 09:58:44 -0000 Authentication-Results: pb1.pair.com header.from=news@sea.gmane.org; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=php-php-dev@m.gmane.org; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain m.gmane.org designates 80.91.229.2 as permitted sender) X-PHP-List-Original-Sender: php-php-dev@m.gmane.org X-Host-Fingerprint: 80.91.229.2 main.gmane.org Linux 2.5 (sometimes 2.4) (4) Received: from [80.91.229.2] ([80.91.229.2:60980] helo=ciao.gmane.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 39/9B-00543-D0ADB754 for ; Sun, 10 Dec 2006 04:58:09 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GtLR5-0004EI-7V for internals@lists.php.net; Sun, 10 Dec 2006 10:57:31 +0100 Received: from 115.84-48-233.nextgentel.com ([84.48.233.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Dec 2006 10:57:31 +0100 Received: from sb by 115.84-48-233.nextgentel.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Dec 2006 10:57:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: internals@lists.php.net Date: Sun, 10 Dec 2006 10:57:22 +0100 Lines: 115 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gmane-NNTP-Posting-Host: 115.84-48-233.nextgentel.com User-Agent: Thunderbird 2.0b1 (X11/20061210) X-Enigmail-Version: 0.94.1.0 Sender: news Subject: [RFC] Magic Method that handles unset($object) From: sb@sebastian-bergmann.de (Sebastian Bergmann) Consider the following code: parentO = $this; $this->children[] = $child; } } class Child { public $parentO = null; public function __construct() { print "Child::__construct()\n"; } public function __destruct() { print "Child::__destruct()\n"; } } function setup() { $parent = new ParentC; $child = new Child; $parent->addChild( $child ); return $parent; } while( true ) { $parent = setup(); unset( $parent ); } ?> This code prints ParentC::__construct() Child::__construct() ParentC::__construct() Child::__construct() . . . instead of ParentC::__construct() Child::__construct() Child::__destruct() ParentC::__destruct() ParentC::__construct() Child::__construct() Child::__destruct() ParentC::__destruct() . . . because unset($parent) decrements the refcount from 2 to 1 as the $child object that is aggregated by the $parent object still holds a reference to its aggregating object. The infinite while() loop is used to hide the fact that the objects are destructed at interpreter shutdown. While this works, it is not desirable in the context from which this small reproducible script is extracted. A possible solution to this problem would be the introduction of yet another "magic" method. This method would be automatically called when unset() is called on an object that implements it. Unfortunately, the name __unset() is already taken. Assuming we had such a method, the following version of ParentC would behave as desired: children = array(); } public function addChild( $child ) { $child->parentO = $this; $this->children[] = $child; } } ?> Is there another solution to this problem (apart from explicitly unsetting the $children array on the $parent object)?And even if there is I think that this method would be usefull. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69