On Fri, May 18, 2018 at 1:59 PM Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 17 May 2018 10:35:11 BST, Etienne Kneuss <col...@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.
