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-

<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



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php


Reply via email to