On Fri, Sep 6, 2024, at 20:07, Claude Pache wrote:
>
>
>> Le 5 sept. 2024 à 18:03, John Coggeshall <[email protected]> a écrit :
>>
>>
>>> As per my previous email to the list, I have now created the official RFC
>>> to deprecate calling json_serialize() on instances of classes marked with
>>> ZEND_ACC_NOT_SERIALIZABLE.
>>
>> I would suggest we take a step back from this and look at it with a bit more
>> of a wider lens. It seems to me that this would be a good place to have an
>> attribute (e.g. `#[NotSerializable]` ) that could be defined for any class
>> (with `ZEND_ACC_NOT_SERIALIZABLE` being automatically given this
>> attribute)? It just seems to be a more holistic approach that makes sense,
>> rather than basing it on internal engine stuff and/or limiting it to
>> internal objects.
>>
>> Coogle
>>
> Hi,
>
> An attribute adds very little value. It doesn’t add new capability, because
> you can achieve the same effect with a serialiser that throws
> unconditionally; it is just a nicer syntax. People generally don’t bother
> making their classes unserialisable unless they have a good reason; having an
> attribute won’t really change that.
You also need to ensure that you make it final, as someone could extend your
class and make your borked serializer work.
> The core problem is that objects are json-serialisable by default, although
> most of them are not supposed to be json-serialised. Taking a second step
> back, if we really want to solve the issue, one should:
>
> * for internal classes, determine which ones could be json-serialisable (at
> least, stdClass); for all other classes, `json_encode(...)` shall be disabled
> (after a deprecation period);
> * for user-defined classes, the user shall opt into json-serialisability,
> either by extending a json-serialisable class, or by using an {attribute /
> magic method / interface} (chose your bikeshed colour).
>
> —Claude
I also agree with this to a point: there is the
https://www.php.net/manual/en/class.jsonserializable.php interface, after all.
— Rob
