On Sep 6 2024, at 2:07 pm, Claude Pache <claude.pa...@gmail.com> wrote:
>
>
> > 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.
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
