Re: [PHP-DEV] RFC Weakrefs

2019-02-05 Thread Rowan Collins
On Tue, 5 Feb 2019 at 16:06, Dennis Birkholz 
wrote:

> Maybe for PHP 8 we
> will decide to require all classes to be serializable except classes
> that implement the Unserializable interface or something... Or the magic
> __isSerializable() method that can decide this at runtime for the actual
> state of an object without failing hard when trying it.
>


I agree, it can be very confusing if you have something like a SimpleXML
object buried somewhere, and your serialize() call blows up. (See the
example I've raised a couple of times where Exceptions may or may not be
serializable, because they slurp up objects from everywhere in their
backtrace.)

I was going to suggest this would fit with the discussion Nikita raised
about adding a new serialization mechanism, but thinking about it more, I'm
not sure how the API for this would work. If you don't recursively check
that the properties of an object are also serializable, the call is
useless; but if you do, it's really no different from try {
serialize($foo); } catch {}

Regards,
-- 
Rowan Collins
[IMSoP]


Re: [PHP-DEV] RFC Weakrefs

2019-02-05 Thread Girgias
On Tue, 5 Feb 2019 at 17:06, Dennis Birkholz 
wrote:

> So I would really prefer the WeakReference class would just be
> serializable with all the consequences you outlined. Maybe for PHP 8 we
> will decide to require all classes to be serializable except classes
> that implement the Unserializable interface or something... Or the magic
> __isSerializable() method that can decide this at runtime for the actual
> state of an object without failing hard when trying it.
>
> Greets
> Dennis
>

That on its own would need an RFC AFAIK and I'm not really a fan of this
hypothetical change.
Also it feels kind of backwards imho. Why should I specify that something
is NOT serializable
when serialisation is a behaviour that usually needs special care with?

Also what would happen when someone does the typical thing to prevent
serialization:
public function __sleep() { throw new Exception(); }

Best regards

George P. Banyard


Re: [PHP-DEV] RFC Weakrefs

2019-02-05 Thread Dennis Birkholz

Hi Nikita,

On 05.02.19 16:50, Nikita Popov wrote:
Serialization for weak refs is a bit tricky, and I feel like supporting 
it could easily become a foot-gun. The fundamental problem is that for 
serialization to produce a meaningful value, the object referenced by a 
WeakReference must also be part of the serialized object graph as a 
strong reference somewhere. Otherwise, the WeakReference will 
immediately turn into a dud when unserialization ends, because the 
object it references is no longer live.


I think from a technical perspective, supporting serialization should be 
possible and not overly hard, it's more a question of whether we want 
to. As another data point, Java does not support serialization for 
WeakReference.


my fundamental problem here is that you can not reliably find out if 
something can be serialized or not. Each class that is not serializable 
by documentation/implementation but does not provide some programatical 
way of checking this adds another burden to create a special case for 
that class.


So I would really prefer the WeakReference class would just be 
serializable with all the consequences you outlined. Maybe for PHP 8 we 
will decide to require all classes to be serializable except classes 
that implement the Unserializable interface or something... Or the magic 
__isSerializable() method that can decide this at runtime for the actual 
state of an object without failing hard when trying it.


Greets
Dennis

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



Re: [PHP-DEV] RFC Weakrefs

2019-02-05 Thread Nikita Popov
On Tue, Feb 5, 2019 at 4:11 PM Dennis Birkholz 
wrote:

> Hi Joe,
>
> On 02.02.19 09:35, Joe Watkins wrote:
> > Some time ago I brought this up for discussion, and last night was
> reminded
> > of it's existence, and so this morning rebased and reworked the patch a
> > little based on the feedback I got back then.
> >
> > Since it was long ago, and there's no particular rush, I don't intend to
> > open voting until the current policy adjustment RFC's are resolved, but
> > wanted to give everyone a heads up and ask for any feedback you may have
> at
> > this time.
>
> thanks for proposing to bring weak references into core, I myself would
> have needed them once or twice.
>
> One point from the RFC bothers me:
>
> > The proposed API:
> > - does not support serialization
>
> That is a really unfortunate decision, I would really like to have them
> serializable. Otherwise if you want to persist a weak ref you always
> have to convert them to a real ref before serialization and back
> afterwards. I would really like to have this transparency build in.
> Would be great if that could be added.
>

Serialization for weak refs is a bit tricky, and I feel like supporting it
could easily become a foot-gun. The fundamental problem is that for
serialization to produce a meaningful value, the object referenced by a
WeakReference must also be part of the serialized object graph as a strong
reference somewhere. Otherwise, the WeakReference will immediately turn
into a dud when unserialization ends, because the object it references is
no longer live.

I think from a technical perspective, supporting serialization should be
possible and not overly hard, it's more a question of whether we want to.
As another data point, Java does not support serialization for
WeakReference.

Nikita


Re: [PHP-DEV] RFC Weakrefs

2019-02-05 Thread Dennis Birkholz

Hi Joe,

On 02.02.19 09:35, Joe Watkins wrote:

Some time ago I brought this up for discussion, and last night was reminded
of it's existence, and so this morning rebased and reworked the patch a
little based on the feedback I got back then.

Since it was long ago, and there's no particular rush, I don't intend to
open voting until the current policy adjustment RFC's are resolved, but
wanted to give everyone a heads up and ask for any feedback you may have at
this time.


thanks for proposing to bring weak references into core, I myself would 
have needed them once or twice.


One point from the RFC bothers me:


The proposed API:
- does not support serialization


That is a really unfortunate decision, I would really like to have them 
serializable. Otherwise if you want to persist a weak ref you always 
have to convert them to a real ref before serialization and back 
afterwards. I would really like to have this transparency build in. 
Would be great if that could be added.


I am a little surprised how often the "is not serializable" label is put 
on something proposed in an RFC and how little that seem to bother 
anybody. That just makes serializing data much more complicated/prone to 
errors/exception.


Thanks for your work,
Dennis

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



Re: [PHP-DEV] RFC Weakrefs

2019-02-02 Thread Benjamin Morel
I was precisely hoping there was a WeakRef implementation the other day.
This would be very useful for a simple data mapper, where you could keep
references to loaded objects and a cache of their original properties, to
compute the changeset to sync to the DB when save()ing them.
WeakRefs would allow to automatically clean up the cache of loaded
properties when the object goes out of scope and is reclaimed by the GC.

So, FWIW, big +1 from me, and thank you for the RFC and the PR! 

Ben

On Sat, 2 Feb 2019 at 09:35, Joe Watkins  wrote:

> Morning internals,
>
> Some time ago I brought this up for discussion, and last night was reminded
> of it's existence, and so this morning rebased and reworked the patch a
> little based on the feedback I got back then.
>
> Since it was long ago, and there's no particular rush, I don't intend to
> open voting until the current policy adjustment RFC's are resolved, but
> wanted to give everyone a heads up and ask for any feedback you may have at
> this time.
>
> https://wiki.php.net/rfc/weakrefs
>
> Cheers
> Joe
>


Re: [PHP-DEV] RFC WeakRefs

2018-05-18 Thread Rowan Collins
On 18 May 2018 13:15:21 BST, Etienne Kneuss  wrote:
>On Fri, May 18, 2018 at 1:59 PM Rowan Collins 
>wrote:
>
>> On 17 May 2018 10:35:11 BST, Etienne Kneuss  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]

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



Re: [PHP-DEV] RFC WeakRefs

2018-05-18 Thread Etienne Kneuss
On Fri, May 18, 2018 at 1:59 PM Rowan Collins 
wrote:

> On 17 May 2018 10:35:11 BST, Etienne Kneuss  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.


Re: [PHP-DEV] RFC WeakRefs

2018-05-18 Thread Rowan Collins
On 17 May 2018 10:35:11 BST, Etienne Kneuss  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).

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]

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



Re: [PHP-DEV] RFC WeakRefs

2018-05-17 Thread Joe Watkins
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

On Thu, May 17, 2018 at 11:35 AM, Etienne Kneuss  wrote:

> On Thu, May 17, 2018 at 8:10 AM Joe Watkins  wrote:
>
>> 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
>
>


Re: [PHP-DEV] RFC WeakRefs

2018-05-17 Thread Etienne Kneuss
On Thu, May 17, 2018 at 8:10 AM Joe Watkins  wrote:

> 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


Re: [PHP-DEV] RFC WeakRefs

2018-05-17 Thread Joe Watkins
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 
wrote:

> On 17 May 2018 07:09:28 BST, Joe Watkins  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]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


Re: [PHP-DEV] RFC WeakRefs

2018-05-17 Thread Rowan Collins
On 17 May 2018 07:09:28 BST, Joe Watkins  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]

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