Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:21150 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70495 invoked by uid 1010); 9 Dec 2005 18:25:32 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 70480 invoked from network); 9 Dec 2005 18:25:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 9 Dec 2005 18:25:32 -0000 X-Host-Fingerprint: 80.237.132.12 wp005.webpack.hosteurope.de Linux 2.5 (sometimes 2.4) (4) Received: from ([80.237.132.12:42925] helo=wp005.webpack.hosteurope.de) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 1A/CF-48939-9FBC9934 for ; Fri, 09 Dec 2005 13:24:57 -0500 Received: by wp005.webpack.hosteurope.de running Exim 4.43 using esmtpa from dslb-084-057-020-113.pools.arcor-ip.net ([84.57.20.113] helo=[192.168.0.101]) id 1Ekmup-00063e-4m; Fri, 09 Dec 2005 19:24:19 +0100 In-Reply-To: <7.0.0.16.2.20051209090744.05acc7f0@zend.com> References: <43970D54.1040206@zend.com> <63053C31-56D1-49A3-8D24-4FC41188A92A@mac.com> <7.0.0.16.2.20051208210843.059ef560@zend.com> <4399B2D7.6020500@iamjochem.com> <7.0.0.16.2.20051209090744.05acc7f0@zend.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-ID: Cc: Jochem Maas , Alan Pinstein , PHP internals Content-Transfer-Encoding: 7bit Date: Fri, 9 Dec 2005 19:24:17 +0100 To: Andi Gutmans X-Mailer: Apple Mail (2.746.2) Subject: Re: [PHP-DEV] $this->this and avoiding circular references From: dz@bitxtender.com (=?ISO-8859-1?Q?David_Z=FClke?=) Would you mind explaining that "indirect property accessing" method, Andi? Or did you mean avoiding circular references altogether by having a third "intermediate" layer that would return the respective object when handed a GUID or something, so that effectively, one of the partners in the circle doesn't store the other partner directly, but just a unique identifier usind which you can retrieve it? (that's the way you have to do it in JavaScript if you don't want IE to crash due to memleaks when referencing from DOM elements to JS objects and vice versa) Thanks, - David Am 09.12.2005 um 18:08 schrieb Andi Gutmans: > Sorry about that. I think it might be a problem with the server not > my client. > If it persists please let me know. > > At 08:37 AM 12/9/2005, Jochem Maas wrote: >> Andi - your email client seems to be leaking :-) >> >> Andi Gutmans wrote: >>> Hi Alan, >>> Generally speaking, if you create a circular reference (whether >>> by reference or by value), then you will have a "memory leak" >>> until the end of the request. This is not only true for objects >>> (and circular references might be indirect) but also for arrays. >>> This is a side-effect of reference counting systems, but within >>> the way PHP is used within a request/response paradigm, it >>> shouldn't be a real limiting factor in real-life usage. On the >>> contrary, for these kind of apps, garbage collecting systems have >>> potential to be significantly slower. >>> Andi >>> At 08:15 PM 12/7/2005, Alan Pinstein wrote: >>> >>>> My question is closely related to the one discussed on this php-dev >>>> thread: >>>> >>>> http://thread.gmane.org/gmane.comp.php.devel/32430 >>>> >>>> Someone just sent me this link, which I didn't find myself when >>>> searching b/c the searches strip "this" from queries. >>>> >>>> Anyway, the question is related to reference counting of objects >>>> when >>>> assigned by value and by reference. It is a very important OO topic >>>> as the ability to have a non-ref-counted object "handle" is >>>> basically >>>> requisite to prevent circular reference deadlocks in OO projects. >>>> >>>> If the way I have proposed doesn't work, then what is the official >>>> way? And there *must* be one, otherwise, there is no way to avoid >>>> huge memory leaks (deferred release until end-of-script, I know, >>>> but >>>> it's a memory leak in the context of the script while it's running) >>>> with this kind of OO arrangement. >>>> >>>> In particular what confuses me is, why does, at least on PHP 5.0.4, >>>> this: >>>> >>>> $obj = &$this->this; // doesn't seem to increment the >>>> refcount of the >>>> object >>>> >>>> behaves differently from: >>>> >>>> $obj = &$this; // does seem to increment the refcount >>>> to the object >>>> >>>> References to $this should not only be valid, but are pretty much >>>> required for proper memory management in an OO environment, unless >>>> there is some other sanctioned way to get a weak reference... now I >>>> am not sure if the fact that making a & reference to an object >>>> doesn't increment the refcount is intended behavior, or an >>>> unintended >>>> side effect that may change. This is one of my major questions. >>>> >>>> Also, in regards to the thread linked above, I'd say that making >>>> & $this an error is not desirable behavior; but maybe changing the >>>> value of $this should be (ie in C terms, $this is not an lvalue). >>>> Although, in C++/Obj-C you *can* even change this/self... in fact >>>> it's common in Obj-C: >>>> >>>> - (id) init >>>> { >>>> if (self = [super init]) { /* etc */ } >>>> return self; >>>> } >>>> >>>> Of course PHP is not Obj-C, but it's OO and garbage collected in a >>>> similar way, so PHP has the same need for manipulating $this; that >>>> is, creating weak references. >>>> >>>> Alan >>>> >>>> >>>> On Dec 7, 2005, at 11:27 AM, Antony Dovgal wrote: >>>> >>>>> On 07.12.2005 18:40, Alan Pinstein wrote: >>>>> >>>>>> Hi all- >>>>> >>>>> >>>>> >>>>> Please use php-general@lists.php.net for questions regarding >>>>> development *in* PHP. >>>>> -- >>>>> Wbr, Antony Dovgal >>>> >>>> >>>> -- >>>> PHP Internals - PHP Runtime Development Mailing List >>>> To unsubscribe, visit: http://www.php.net/unsub.php > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >