Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102119
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.193 as permitted sender)
MIME-Version: 1.0
References: <CAL=_i_nqLdboRr3jYBTX1_2OOiSePq1ZveiZHfiQSH3DF3WtNw@mail.gmail.com>
 <CACQesk5g0UGhgJ4qyPrmrv--u1X_b9NdvFcP=2ZPfNODOQ5PwQ@mail.gmail.com> <47A0DB53-F5B8-4A3E-8288-28154A342ED9@gmail.com>
In-Reply-To: <47A0DB53-F5B8-4A3E-8288-28154A342ED9@gmail.com>
Date: Fri, 18 May 2018 14:15:21 +0200
Message-ID: <CACQesk48mqicCp1OAB-sfLc0tWW81197_4R8z=kEMPXMCfZhvg@mail.gmail.com>
To: internals Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000084e3cc056c79f007"
Subject: Re: [PHP-DEV] RFC WeakRefs
From: colder@php.net (Etienne Kneuss)

--00000000000084e3cc056c79f007
Content-Type: text/plain; charset="UTF-8"

On Fri, May 18, 2018 at 1:59 PM Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 17 May 2018 10:35:11 BST, Etienne Kneuss <colder@php.net> wrote:
> >That said, if the plan is to subsume pecl-weakref, I suggest we also
> >reimplement weakmaps, which offer a convenient way of storing
> >meta/cache
> >data and is not implementable in userland without trade-offs.
>
> It looks to me like WeakMap would be fairly trivial to implement in
> userland as a combination of WeakRef, ArrayAccess, Iterable, and an
> internal SplObjectStorage for the ability to use objects as keys (although
> I'm not clear why it uses object keys in the first place).
>

In weakmaps it is the keys that are weak, hence objects only; the values
are arbitrary data associated with them.
The goal is to provide a way to associate metadata that may also be
collected in case the key gets collected.
In some sense it would behave as if this metadata was stored as a property
of the object, only it is stored externally in a weakmap.

>
>
>> The only part that seems hard to write efficiently is Countable support,
>> since you'd have to iterate the internal hash checking for unset objects. I
>> suppose iteration would also slow down a bit of lots of the references were
>> now unset. Is that the trade-off you're referring to, that the C
>> implementation has some magic to avoid?
>>
>
You indeed would need a O(n) count. But it's not the only issue: you also
should DELREF the values associated with invalid weakrefs once in a while,
and doing this manually makes this entire thing less attractive.

--00000000000084e3cc056c79f007--