Morning internals,
I'd like to raise for discussion https://wiki.php.net/rfc/weakrefs
Am I missing anything ?
Cheers
Joe
Morning internals,
I'd like to raise for discussion https://wiki.php.net/rfc/weakrefs
Hi Joe,
Sounds exciting!
What does this look like from userland? I'm guessing you wrap the object you want a weak reference to in a special container? If so, has there been any previous discussion of baking it further into the language, e.g. as a keyword to wrap, and an implicit unwrap? Obviously something that could be revisited later, just curious if it's been considered.
Cheers,
--
Rowan Collins
[IMSoP]
Morning Rowan,
I've updated the RFC with a description of the API and comparison to the
current WeakRef API documented by the pecl extension.
Example code can be found in tests also ...
Cheers
Joe
On Thu, May 17, 2018 at 9:36 AM, Rowan Collins [email protected]
wrote:
Morning internals,
I'd like to raise for discussion https://wiki.php.net/rfc/weakrefs
Hi Joe,
Sounds exciting!
What does this look like from userland? I'm guessing you wrap the object
you want a weak reference to in a special container? If so, has there been
any previous discussion of baking it further into the language, e.g. as a
keyword to wrap, and an implicit unwrap? Obviously something that could be
revisited later, just curious if it's been considered.Cheers,
--
Rowan Collins
[IMSoP]
Morning internals,
I'd like to raise for discussion https://wiki.php.net/rfc/weakrefs
Am I missing anything ?
I'm all for implementing all this natively, the way it was implemented in
pecl-weakref always felt hackish and brittle.
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.
Best,
Cheers
Joe
Morning,
I'm aware the pecl extension also has weakmap support.
I think we've enough time to vote on the implementation of weakrefs, and
then think about how we want weak maps to work and vote on the
implementation of that.
Cheers
Joe
Morning internals,
I'd like to raise for discussion https://wiki.php.net/rfc/weakrefs
Am I missing anything ?
I'm all for implementing all this natively, the way it was implemented in
pecl-weakref always felt hackish and brittle.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.Best,
Cheers
Joe
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).
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?
Regards,
--
Rowan Collins
[IMSoP]
On Fri, May 18, 2018 at 1:59 PM Rowan Collins [email protected]
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.
On Fri, May 18, 2018 at 1:59 PM Rowan Collins [email protected]
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.
Ah, that makes more sense; there didn't seem to be any accrual description in the manual of what they were for; maybe I was looking in the wrong place. In that case, I understand your request to include it, and apologise for the noise :)
Regards,
--
Rowan Collins
[IMSoP]
Morning internals,
I'd like to raise for discussion https://wiki.php.net/rfc/weakrefs
Am I missing anything ?
Cheers
Joe
Hi,
Would we benefit having notification mechanism in weak references? I
implemented such notification in https://github.com/pinepain/php-ref,
(used https://github.com/colder/php-weakref as a reference). The only
issue is that how notification logic should behave when unclean shutdown
happens, the culprit is some exception thrown which leads to referent
object destruction and this uncertainty doubles when notification logic
(callback) also triggers exception. So I bring this question more for
discussion and it could be definitely implemented later (small working
feature is better then large non-working one).
Seen that there is weak data structs discussion below, there is
https://github.com/pinepain/php-object-maps weak/soft map implementatoin
I made at the time of php-ref extension. It somehow based on java maps
interface and I think with notification interface for weak refs it's
fairly simple to implement such maps in userland THOUGH without
notification, having primitive weakmap in the psl needs to be taken with
care to do not end up like other psl data structs.