Re: RFC: Deprecate json_encode() on classes marked as non-serializable
| From: | Rob Landers | Date: | Fri, 06 Sep 2024 18:44:36 +0000 |
| Subject: | Re: RFC: Deprecate json_encode() on classes marked as non-serializable | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-125456@lists.php.net to get a copy of this message | ||
On Fri, Sep 6, 2024, at 20:07, Claude Pache wrote:
>
>
>> Le 5 sept. 2024 à 18:03, John Coggeshall <john@coggeshall.org> 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