Re: RFC: Deprecate json_encode() on classes marked as non-serializable

> 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. 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