Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125454
Date: Fri, 6 Sep 2024 14:10:40 -0400
To: Claude Pache <claude.pache@gmail.com>
Cc: Philip Hofstetter <phofstetter@sensational.ch>, PHP internals
 <internals@lists.php.net>
Message-ID: <2ED0D37F-3DB9-48BF-8C32-C4A036E71089@getmailspring.com>
In-Reply-To: <B3E431AC-074E-42B0-B770-139456579861@gmail.com>
References: <B3E431AC-074E-42B0-B770-139456579861@gmail.com>
Subject: Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as
 non-serializable
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66db45a0_6b8b4567_7e04"
From: john@coggeshall.org (John Coggeshall)

--66db45a0_6b8b4567_7e04
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline



On Sep 6 2024, at 2:07 pm, Claude Pache <claude.pache=40gmail.com> wrote:=

>
>
> > Le 5 sept. 2024 =C3=A0 18:03, John Coggeshall <john=40coggeshall.org>=
 a =C3=A9crit :
> >
> > > As per my previous email to the list, I have now created the offici=
al R=46C to deprecate calling json=5Fserialize() on instances of classes =
marked with ZEND=5FACC=5FNOT=5FSERIALIZABLE.
> >
> > I would suggest we take a step back from this and look at it with a b=
it more of a wider lens. It seems to me that this would be a good place t=
o have an attribute (e.g. =23=5BNotSerializable=5D ) that could be define=
d for any class (with ZEND=5FACC=5FNOT=5FSERIALIZABLE being automatically=
 given this attribute)=3F It just seems to be a more holistic approach th=
at makes sense, rather than basing it on internal engine stuff and/or lim=
iting it to internal objects.
> > Coogle
> >
>
> Hi,
>
> An attribute adds very little value. It doesn=E2=80=99t add new capabil=
ity, because you can achieve the same effect with a serialiser that throw=
s unconditionally; it is just a nicer syntax. People generally don=E2=80=99=
t bother making their classes unserialisable unless they have a good reas=
on; having an attribute won=E2=80=99t 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
--66db45a0_6b8b4567_7e04
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div class=3D=22gmail=5Fquote=5Fattribution=22>On Sep 6 2024, at =
2:07 pm, Claude Pache &lt;claude.pache=40gmail.com&gt; wrote:</div><block=
quote><br><div><br><blockquote><div>Le 5 sept. 2024 =C3=A0 18:03, John Co=
ggeshall &lt;john=40coggeshall.org&gt; a =C3=A9crit :</div><br><div><br><=
blockquote><div><div><div class=3D=22gmail=5Fsignature=22><div>As per my =
previous email to the list, I have now created the official R=46C to depr=
ecate calling json=5Fserialize() on instances of classes marked with ZEND=
=5FACC=5FNOT=5FSERIALIZABLE.</div></div></div></div></blockquote><div><di=
v><div class=3D=22gmail=5Fsignature=22><br><div>I would suggest we take a=
 step back from this and look at it with a bit more of a wider lens. It s=
eems to me that this would be a good place to have an attribute (e.g. <co=
de>=23=5BNotSerializable=5D</code>&nbsp;)&nbsp; that could be defined for=
 any class (with <code>ZEND=5FACC=5FNOT=5FSERIALIZABLE</code>&nbsp; being=
 automatically given this attribute)=3F It just seems to be a more holist=
ic approach that makes sense, rather than basing it on internal engine st=
uff and/or limiting it to internal objects.</div><br><div>Coogle</div><br=
><br></div></div></div></div></blockquote><br></div><div>Hi,</div><div><b=
r></div><div>An attribute adds very little value. It doesn=E2=80=99t 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=E2=80=99t bother making their classes unserialisable unless they hav=
e a good reason; having an attribute won=E2=80=99t really change that.</d=
iv></blockquote><br><div>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 internall=
y within the engine that a class can be flagged as not serializable, but =
yet not expose that same ability to userspace.</div><br><div>Coogle</div>
--66db45a0_6b8b4567_7e04--