Newsgroups: php.internals,php.internals
Path: news.php.net
Xref: news.php.net php.internals:125452 php.internals:125453
Message-ID: <B3E431AC-074E-42B0-B770-139456579861@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C17DB746-EEEF-4C38-A33A-37CC95F6E9ED"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as
 non-serializable
Date: Fri, 6 Sep 2024 20:07:07 +0200
In-Reply-To: <98553A91-FD3F-4E1B-91D9-D8B00CAD5FC5@getmailspring.com>
Cc: Philip Hofstetter <phofstetter@sensational.ch>,
 PHP internals <internals@lists.php.net>
To: John Coggeshall <john@coggeshall.org>
References: <CAGKNXQG32aF58gPnf1ywbmde72F_Wwjib0oXhN_ve6336RnQXg@mail.gmail.com>
 <98553A91-FD3F-4E1B-91D9-D8B00CAD5FC5@getmailspring.com>
From: claude.pache@gmail.com (Claude Pache)


--Apple-Mail=_C17DB746-EEEF-4C38-A33A-37CC95F6E9ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 5 sept. 2024 =C3=A0 18:03, John Coggeshall <john@coggeshall.org> a =
=C3=A9crit :
>=20
>=20
> 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.
>=20
> 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.
>=20
> Coogle
>=20
>=20

Hi,

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 =
have a good reason; having an attribute won=E2=80=99t 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).

=E2=80=94Claude





--Apple-Mail=_C17DB746-EEEF-4C38-A33A-37CC95F6E9ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>Le 5 sept. 2024 =C3=A0 18:03, John Coggeshall =
&lt;john@coggeshall.org&gt; a =C3=A9crit :</div><br =
class=3D"Apple-interchange-newline"><div><br><blockquote><div><div><div =
class=3D"gmail_signature"><div>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.</div></div></div></div></blockquote><div><div><=
div class=3D"gmail_signature"><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 seems =
to me that this would be a good place to have an attribute (e.g. =
<code>#[NotSerializable]</code>&nbsp;)&nbsp; that could be defined for =
any class (with <code>ZEND_ACC_NOT_SERIALIZABLE</code>&nbsp; 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.</div><br><div>Coogle</div><br><br></div></div></div></div></block=
quote><br></div><div>Hi,</div><div><br></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 have a good reason; having an =
attribute won=E2=80=99t really change that.</div><div><br></div><div>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:</div><div><br></div><div>* 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);</div><div>* 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).</div><div><br></div><div>=E2=80=94Claude</div><div><br></div><div=
><br></div><div><br></div><br></body></html>=

--Apple-Mail=_C17DB746-EEEF-4C38-A33A-37CC95F6E9ED--