Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:21161
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
In-Reply-To: <7.0.0.16.2.20051209142424.08ae3ea0@zend.com>
References: <AC5F3B0F-49B6-4CB7-87D1-45767F8D9DD5@mac.com> <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> <BECCA70F-A69B-4BAB-8706-7DFC1ABEDC28@bitxtender.com> <7.0.0.16.2.20051209142424.08ae3ea0@zend.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-ID: <CCF7C927-2F37-4974-A886-C0DACC276852@mac.com>
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Date: Sat, 10 Dec 2005 09:08:40 -0500
To: Andi Gutmans <andi@zend.com>
Subject: Re: [PHP-DEV] $this->this and avoiding circular references
From: apinstein@mac.com (Alan Pinstein)

Heh no problem. I'll cc the list for you.

So basically propel creates an object to represent each table in a =20
DB. Foreign key relationships are maintained, and the propel objects =20
cache the results.

So, in a simple scenario with "Account" and "Transactions", your =20
"Account" object keeps an internal "collection" of transactions and =20
each "transaction" keeps an internal reference to its "Account". =20
There's the circular reference.

So, if you could explain your idea (a) as a solution to this =20
architecture, that'd be great.

Also, why don't you describe (b) anyway just for fun :)

Alan

On Dec 9, 2005, at 5:35 PM, Andi Gutmans wrote:

> Not cc:'ing internals@ because for some reason it doesn't seem to =20
> like me today (problem with our mail queue and lists.php.net)
> Well I didn't have an exact solution in mind because I don't know =20
> the exact problem you have and how you'd like to solve it. I was =20
> thinking of two ways:
> a) Doing some kind of id to object mapping (possibly using =20
> overloading __get/__set).
> b) Come to think of it, my (b), indirect references, isn't a good =20
> idea :)
>
> Andi
>
> At 10:24 AM 12/9/2005, David Z=FClke wrote:
>> 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 =20
>>>>>> 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 =20
>>>>>> 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 =20
>>>>>> 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 =20
>>>>>> running)
>>>>>> with this kind of OO arrangement.
>>>>>>
>>>>>> In particular what confuses me is, why does, at least on PHP =20
>>>>>> 5.0.4,
>>>>>> this:
>>>>>>
>>>>>> $obj =3D &$this->this;    // doesn't seem to increment the
>>>>>> refcount of the
>>>>>> object
>>>>>>
>>>>>> behaves differently from:
>>>>>>
>>>>>> $obj =3D &$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, =20
>>>>>> unless
>>>>>> there is some other sanctioned way to get a weak reference... =20
>>>>>> 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 =20=

>>>>>> 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 =3D [super init]) { /* etc */ }
>>>>>>     return self;
>>>>>> }
>>>>>>
>>>>>> Of course PHP is not Obj-C, but it's OO and garbage collected =20
>>>>>> in a
>>>>>> similar way, so PHP has the same need for manipulating $this; =20
>>>>>> 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-
>>>>>>>
>>>>>>> <skip>
>>>>>>>
>>>>>>> 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
>>>
>