Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53995
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CACs9DU71DQ059X6OUfBPkm7UBRwOJv3fg7ku2=7E3Jtk8ybZ=A@mail.gmail.com>
References: <CAH-PCH4M0vo9dbqAjRcSMXmA0NKsN57ZWQBw0KOCJ-iShx1D4A@mail.gmail.com>
	<CAKUjMCWJW6nf=Sede6AiE_fwC+1dMf==UMTg52q7zJDihsnOZQ@mail.gmail.com>
	<CAH-PCH7sfkFJDJj8vb-uuDwmhsFp0ipYYaYRMB=o3drPZyyisA@mail.gmail.com>
	<4E22DDD0.20105@toolpark.com>
	<CACs9DU7Y68jSSLYKkVzHRBqyQ2wvZUcgTgbB31nGzAHiyRy4iQ@mail.gmail.com>
	<CACs9DU71DQ059X6OUfBPkm7UBRwOJv3fg7ku2=7E3Jtk8ybZ=A@mail.gmail.com>
Date: Sun, 17 Jul 2011 17:47:31 +0200
Message-ID: <CAEZPtU4jkT9yn8YEF=zMowUW7xgEZxm7BUyRBcSTim3_9K=MaA@mail.gmail.com>
To: Hannes Landeholm <landeholm@gmail.com>
Cc: internals@lists.php.net, Ferenc Kovacs <tyra3l@gmail.com>, 
	Lars Schultz <lars.schultz@toolpark.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] weak references
From: pierre.php@gmail.com (Pierre Joye)

hi,


On Sun, Jul 17, 2011 at 5:40 PM, Hannes Landeholm <landeholm@gmail.com> wro=
te:
> On 17 July 2011 12:38, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>>
>> =A0Hannes, now you should have karma for the rfc namespace, so you can
>> now extend the article with your suggestions.
>
>
>
> Great, I'll start contributing ASAP. What's the next step after the RFC i=
s
> complete? Testing? Voting?

See https://wiki.php.net/rfc/voting

So 1st discussing then voting ;)

> On 17 July 2011 15:04, Lars Schultz <lars.schultz@toolpark.com> wrote:
>
>> I too would welcome a solution to this problem, I've run into it several
>> times already and always had to use a semi-satisfactory solution. I hadn=
't
>> heard about weak-references before, and I generally like the concept. Wh=
at I
>> am not so sure is wether this makes everything alot more complicated for
>> users who do not know/care about the problem or the solution. Of course =
the
>> impact on those users depends on the actual solution.
>>
>
> If you are writing code that caches objects/relations and that caching ha=
s a
> significant impact on memory usage, you need to care about memory
> allocation/management per definition. So then you have to learn how OOP
> memory managment works (which should be obligatory anyway if you want to
> call yourself a OOP-developer IMO). A common argument to why programmers
> should not start with a garbage collected language is that it prevents th=
em
> from understanding memory allocation concepts.
>
>
>
>> I came at the problem from a different angle and came to a different
>> solution: If I could get the refcount on a certain object, and kept the
>> object stored centrally in one list, I'd know that if the refcount is do=
wn
>> to 1 (or some other constant) that the object ist not in use anymore. I
>> believe that this would be quite a simple PHP addition...a simple functi=
on
>> called: get_ref_count() or something and as I remember, that value is al=
ways
>> stored in the zval...
>>
>> The only other thing that would help would be a callback (or callable)
>> which is triggered by PHP reaching a certain memory-limit, absolute or
>> relative. Then I could clean up memory according to my own business-logi=
c...
>>
>> This way, PHP would not feature something totally new, but one could sti=
ll
>> solve the problem with some work.
>>
>> Do I make any sense at all? Am I missing the point? Anyway, this is an
>> interesting problem.
>>
>> Cheers.
>> Lars
>
>
> It would probably be simple to implement such functionality. However this
> would be bad design since it would violate responsibility isolation. PHP
> should expose as little internal stuff to the userland as possible - unle=
ss
> there are a clear use case for it, and even then it might be a bad idea
> because it could cause BC breaks in future updates. If you write code tha=
t
> depend on reference counts or memory usage - you're doing something wrong=
.
>
> You either need data or you don't. If you need data you reference it. If =
you
> don't reference it the GC will deallocate it. A fundamental part of OOP i=
s
> designing your program so you never reference stuff you don't need. Weak
> references solve the special case where you need the reference for as lon=
g
> as you need the data it references (as long as there are strong reference=
s
> for it). You should have a clear reference graph in your application - th=
ere
> is no magic solution to good object oriented design.
>
> The only scenario I could imagine where you could "free memory"
> spontaneously on demand (when the arbitrary OOM limit is reached) - is if
> that would be cached data. Caching is a very complicated subject that is =
not
> directly related to weak references. Start a separate thread about it and
> present clear use cases if you have anything special in mind.
>
> For example, I need weak references to store a table of "back references"
> between objects for later reference (depends on how you use the objects).=
 If
> A references B i also need a weak reference from B to A so if B should be
> replaced with a C object I need the weak reference from B to A to know th=
at
> A should be updated to point to C instead (if A still exists). This is no=
t
> related to caching.
>
> ~Hannes
>



--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org