Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125421
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 04 Sep 2024 21:41:17 +0200
To: internals@lists.php.net
Message-ID: <dd55ede0-f3f9-4fc1-aa8d-0a335d69bfd3@app.fastmail.com>
In-Reply-To: 
 <CAGKNXQG32aF58gPnf1ywbmde72F_Wwjib0oXhN_ve6336RnQXg@mail.gmail.com>
References: 
 <CAGKNXQG32aF58gPnf1ywbmde72F_Wwjib0oXhN_ve6336RnQXg@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as
 non-serializable
Content-Type: multipart/alternative;
 boundary=2fc240995b9942d29d60589b73e83bfb
From: rob@bottled.codes ("Rob Landers")

--2fc240995b9942d29d60589b73e83bfb
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 3, 2024, at 13:24, Philip Hofstetter wrote:
> Hello,
>=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
> https://wiki.php.net/rfc/deprecate-json_encode-nonserializable
>=20
> I have also created a PR with the implementation here:
>=20
> https://github.com/php/php-src/pull/15724
>=20
> I have considered other options, both constraining the implementation =
to just Generator and/or to add special cases for Generator (and maybe I=
terator), but they either continue to keep the asymmetry between seriali=
ze() and json_encode() and/or are making things even more inconsistent.
>=20
> Please tell me what you think, especially, if you agree that blanked-d=
eprecating all of ZEND_ACC_NOT_SERIALIZABLE classes is acceptable BC-wis=
e (after a bit of deliberation over the weekend, I think it is and most =
json-serializations of such marked classes are probably unintentional).
>=20
> Thanks in advance for all comments
>=20
> Philip
>=20
>=20

Hello Phillip.

I think it would be good to list these non-serializable objects in the R=
FC. It doesn't have to be exhaustive, but the list includes throwables, =
weak-maps, weak-references, closures, fibers, etc. Some people may be re=
lying on this behavior (and I'd be curious to know that use case myself).

I just grepped for @not-serializable in php-src stubs, which appears to =
be the only use of ZEND_ACC_NOT_SERIALIZABLE.

=E2=80=94 Rob
--2fc240995b9942d29d60589b73e83bfb
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Tue, Sep 3, =
2024, at 13:24, Philip Hofstetter wrote:<br></div><blockquote type=3D"ci=
te" id=3D"qt" style=3D""><div dir=3D"ltr"><div>Hello,<br></div><div><div=
><br></div><div class=3D"qt-gmail_signature"><div dir=3D"ltr">As per my =
previous email to the list, I have now created the official RFC to depre=
cate calling json_serialize() on instances of classes marked with ZEND_A=
CC_NOT_SERIALIZABLE.<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr=
"><a href=3D"https://wiki.php.net/rfc/deprecate-json_encode-nonserializa=
ble">https://wiki.php.net/rfc/deprecate-json_encode-nonserializable</a><=
br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">I have also created=
 a PR with the implementation here:<br></div><div dir=3D"ltr"><br></div>=
<div dir=3D"ltr"><a href=3D"https://github.com/php/php-src/pull/15724">h=
ttps://github.com/php/php-src/pull/15724</a><br></div><div dir=3D"ltr"><=
br></div><div dir=3D"ltr">I have considered other options, both constrai=
ning the implementation to just Generator and/or to add special cases fo=
r Generator (and maybe Iterator), but they either continue to keep the a=
symmetry between serialize() and json_encode() and/or are making things =
even more inconsistent.<br></div><div dir=3D"ltr"><br></div><div dir=3D"=
ltr">Please tell me what you think, especially, if you agree that blanke=
d-deprecating all of ZEND_ACC_NOT_SERIALIZABLE classes is acceptable BC-=
wise (after a bit of deliberation over the weekend, I think it is and mo=
st json-serializations of such marked classes are probably unintentional=
).<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">Thanks in advanc=
e for all comments<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr">=
Philip<br></div><div dir=3D"ltr"><br></div><div dir=3D"ltr"><br></div></=
div></div></div></blockquote><div><br></div><div>Hello Phillip.<br></div=
><div><br></div><div>I think it would be good to list these non-serializ=
able objects in the RFC. It doesn't have to be exhaustive, but the list =
includes throwables, weak-maps, weak-references, closures, fibers, etc. =
Some people may be relying on this behavior (and I'd be curious to know =
that use case myself).<br></div><div><br></div><div>I just grepped for&n=
bsp;@not-serializable in php-src stubs, which appears to be the only use=
 of&nbsp;ZEND_ACC_NOT_SERIALIZABLE.<br></div><div><br></div><div id=3D"s=
ig121229152">=E2=80=94 Rob<br></div></body></html>
--2fc240995b9942d29d60589b73e83bfb--