Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125434
Precedence: bulk
MIME-Version: 1.0
References: <CAGKNXQG32aF58gPnf1ywbmde72F_Wwjib0oXhN_ve6336RnQXg@mail.gmail.com>
In-Reply-To: <CAGKNXQG32aF58gPnf1ywbmde72F_Wwjib0oXhN_ve6336RnQXg@mail.gmail.com>
Date: Thu, 5 Sep 2024 11:55:58 +0300
Message-ID: <CAAwdEzCxC=gAxR82DC8ZNNvsDbw8PE_wtZ0CD5LkFM+XAPqHZA@mail.gmail.com>
Subject: Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable
To: Philip Hofstetter <phofstetter@sensational.ch>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000092251f06215b769d"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--00000000000092251f06215b769d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 3, 2024 at 2:27=E2=80=AFPM Philip Hofstetter <phofstetter@sensa=
tional.ch>
wrote:

> Hello,
>
> 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.
>
> https://wiki.php.net/rfc/deprecate-json_encode-nonserializable
>
>
>
Sharing my experience, I never use json_encode on objects but on arrays
(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 an
object, except if it implemented JsonSerializable, but that ship sailed
long ago.

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 publicly
visible properties will be included.
So that's the expected behaviour.

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 one
aims to be symmetrical, and where it can't be, it has a way to stop the
serialization.

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.

Regards,
Alex

--00000000000092251f06215b769d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Tue, Sep 3, 2024 at 2:27=E2=80=AFPM Ph=
ilip Hofstetter &lt;<a href=3D"mailto:phofstetter@sensational.ch">phofstett=
er@sensational.ch</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div><div dir=3D"ltr">Hello,<div><br><div class=3D"gmail_s=
ignature"><div dir=3D"ltr">As per my previous email to the list, I have now=
 created the official RFC to deprecate calling json_serialize() on instance=
s of classes marked with ZEND_ACC_NOT_SERIALIZABLE.</div><div dir=3D"ltr"><=
br></div><div dir=3D"ltr"><a href=3D"https://wiki.php.net/rfc/deprecate-jso=
n_encode-nonserializable" target=3D"_blank">https://wiki.php.net/rfc/deprec=
ate-json_encode-nonserializable</a><br></div><div dir=3D"ltr"><br></div><di=
v dir=3D"ltr"><br></div></div></div></div></div></blockquote><div><br></div=
><div>Sharing my experience, I never use json_encode on objects but on arra=
ys (that are both JSON objects or JSON arrays).</div><div>When I see an obj=
ect implementing JsonSerializable, I think it is the=C2=A0wrong approach,=
=C2=A0and I am usually able to find a better way.</div><div>Maybe if we cou=
ld go back in time, we would not allow json_encode on an object, except if =
it implemented JsonSerializable, but that ship sailed long ago.<br></div><d=
iv><br></div><div>To your proposal, I think the BC break would be pretty bi=
g and I don&#39;t see a way it would pass.</div><div>On=C2=A0<a href=3D"htt=
ps://www.php.net/json_encode">https://www.php.net/json_encode</a> we can re=
ad:</div><div>&gt;=C2=A0If a value to be serialized is an object, then by d=
efault only publicly visible properties will be included.</div><div>So that=
&#39;s the expected behaviour.</div><div><br></div><div>Yes, you can say th=
at encoding as JSON is just &quot;another=C2=A0serialization method&quot;, =
but the default method in PHP, using json_encode()/json_decode(), is not sy=
mmetrical=C2=A0when using objects.</div><div>And here lies the difference w=
ith serialize()/unserialize(), as this one aims to be symmetrical, and wher=
e it can&#39;t be, it has a way to stop the serialization.</div><div><br></=
div><div>I am happy with the current way it works, getting an empty JSON ob=
ject if there are no public properties for a Generator or Closure.</div><di=
v>And I don&#39;t think having an error for them would improve the language=
 in a meaningful way, and the BC break is not worth it.</div><div><br></div=
><div>Regards,<br></div><div>Alex</div><div><br></div></div></div>

--00000000000092251f06215b769d--