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

On Sep 6 2024, at 2:07 pm, Claude Pache <claude.pache@gmail.com> 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. There are plenty of examples in frameworks, etc. where userspace classes are defined that simply shouldn't be serialized for a variety of reasons. It seems odd to me to have the notion internally within the engine that a class can be flagged as not serializable, but yet not expose that same ability to userspace. Coogle