> Le 5 sept. 2024 à 18:03, John Coggeshall <j...@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.
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
