Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125435
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 05 Sep 2024 11:47:57 +0200
To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>,
 "Philip Hofstetter" <phofstetter@sensational.ch>
Cc: "PHP internals" <internals@lists.php.net>
Message-ID: <24ee415a-5963-4b3d-a034-eacf4fed29ca@app.fastmail.com>
In-Reply-To: 
 <CAAwdEzCxC=gAxR82DC8ZNNvsDbw8PE_wtZ0CD5LkFM+XAPqHZA@mail.gmail.com>
References: 
 <CAGKNXQG32aF58gPnf1ywbmde72F_Wwjib0oXhN_ve6336RnQXg@mail.gmail.com>
 <CAAwdEzCxC=gAxR82DC8ZNNvsDbw8PE_wtZ0CD5LkFM+XAPqHZA@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as
 non-serializable
Content-Type: multipart/alternative;
 boundary=3af0aeaaff8a4917ba21d376c995e973
From: rob@bottled.codes ("Rob Landers")

--3af0aeaaff8a4917ba21d376c995e973
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Sep 5, 2024, at 10:55, Alexandru P=C4=83tr=C4=83nescu wrote:
>=20
> On Tue, Sep 3, 2024 at 2:27=E2=80=AFPM Philip Hofstetter <phofstetter@=
sensational.ch> 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 marke=
d with ZEND_ACC_NOT_SERIALIZABLE.
>>=20
>> https://wiki.php.net/rfc/deprecate-json_encode-nonserializable
>>=20
>>=20
>=20
> Sharing my experience, I never use json_encode on objects but on array=
s (that are both JSON objects or JSON arrays).
> When I see an object implementing JsonSerializable, I think it is the =
wrong approach, and I am usually able to find a better way.
> Maybe if we could go back in time, we would not allow json_encode on a=
n object, except if it implemented JsonSerializable, but that ship saile=
d long ago.
>=20
> To your proposal, I think the BC break would be pretty big and I don't=
 see a way it would pass.
> On https://www.php.net/json_encode we can read:
> > If a value to be serialized is an object, then by default only publi=
cly visible properties will be included.
> So that's the expected behaviour.
>=20
> Yes, you can say that encoding as JSON is just "another serialization =
method", but the default method in PHP, using json_encode()/json_decode(=
), is not symmetrical when using objects.
> And here lies the difference with serialize()/unserialize(), as this o=
ne aims to be symmetrical, and where it can't be, it has a way to stop t=
he serialization.
>=20
> I am happy with the current way it works, getting an empty JSON object=
 if there are no public properties for a Generator or Closure.
> And I don't think having an error for them would improve the language =
in a meaningful way, and the BC break is not worth it.
>=20
> Regards,
> Alex
>=20

To add to this, we apparently use json_encode at work to serialize custo=
m exceptions, which appears to work. This RFC would break that, I think.=20

=E2=80=94 Rob
--3af0aeaaff8a4917ba21d376c995e973
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><br></div><div>=
<br></div><div>On Thu, Sep 5, 2024, at 10:55, Alexandru P=C4=83tr=C4=83n=
escu wrote:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div=
 dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"qt-gmail_quote"><d=
iv dir=3D"ltr" class=3D"qt-gmail_attr">On Tue, Sep 3, 2024 at 2:27=E2=80=
=AFPM Philip Hofstetter &lt;<a href=3D"mailto:phofstetter@sensational.ch=
">phofstetter@sensational.ch</a>&gt; wrote:<br></div><blockquote class=3D=
"qt-gmail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:=
0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;bord=
er-left-color:rgb(204, 204, 204);padding-left:1ex;"><div><div dir=3D"ltr=
"><div>Hello,<br></div><div><div><br></div><div class=3D"qt-gmail_signat=
ure"><div dir=3D"ltr">As per my previous email to the list, I have now c=
reated the official RFC to deprecate calling json_serialize() on instanc=
es of classes marked with ZEND_ACC_NOT_SERIALIZABLE.<br></div><div dir=3D=
"ltr"><br></div><div dir=3D"ltr"><a href=3D"https://wiki.php.net/rfc/dep=
recate-json_encode-nonserializable" target=3D"_blank">https://wiki.php.n=
et/rfc/deprecate-json_encode-nonserializable</a><br></div><div dir=3D"lt=
r"><br></div><div dir=3D"ltr"><br></div></div></div></div></div></blockq=
uote><div><br></div><div>Sharing my experience, I never use json_encode =
on objects but on arrays (that are both JSON objects or JSON arrays).<br=
></div><div>When I see an object implementing JsonSerializable, I think =
it is the&nbsp;wrong approach,&nbsp;and I am usually able to find a bett=
er way.<br></div><div>Maybe if we could go back in time, we would not al=
low json_encode on an object, except if it implemented JsonSerializable,=
 but that ship sailed long ago.<br></div><div><br></div><div>To your pro=
posal, I think the BC break would be pretty big and I don't see a way it=
 would pass.<br></div><div>On&nbsp;<a href=3D"https://www.php.net/json_e=
ncode">https://www.php.net/json_encode</a> we can read:<br></div><div>&g=
t;&nbsp;If a value to be serialized is an object, then by default only p=
ublicly visible properties will be included.<br></div><div>So that's the=
 expected behaviour.<br></div><div><br></div><div>Yes, you can say that =
encoding as JSON is just "another&nbsp;serialization method", but the de=
fault method in PHP, using json_encode()/json_decode(), is not symmetric=
al&nbsp;when using objects.<br></div><div>And here lies the difference w=
ith serialize()/unserialize(), as this one aims to be symmetrical, and w=
here it can't be, it has a way to stop the serialization.<br></div><div>=
<br></div><div>I am happy with the current way it works, getting an empt=
y JSON object if there are no public properties for a Generator or Closu=
re.<br></div><div>And I don't think having an error for them would impro=
ve the language in a meaningful way, and the BC break is not worth it.<b=
r></div><div><br></div><div>Regards,<br></div><div>Alex<br></div><div><b=
r></div></div></div></blockquote><div><br></div><div>To add to this, we =
apparently use json_encode at work to serialize custom exceptions, which=
 appears to work. This RFC would break that, I think.&nbsp;</div><div><b=
r></div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--3af0aeaaff8a4917ba21d376c995e973--