Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125438
Date: Thu, 5 Sep 2024 12:03:36 -0400
To: Philip Hofstetter <phofstetter@sensational.ch>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <98553A91-FD3F-4E1B-91D9-D8B00CAD5FC5@getmailspring.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
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="66d9d658_6b8b4567_15a82"
From: john@coggeshall.org (John Coggeshall)

--66d9d658_6b8b4567_15a82
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


> 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.

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.
Coogle


--66d9d658_6b8b4567_15a82
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><blockquote><div><div><div class=3D=22gmail=5Fsignature=22><div>As pe=
r my previous email to the list, I have now created the official R=46C to=
 deprecate calling json=5Fserialize() on instances of classes marked with=
 ZEND=5FACC=5FNOT=5FSERIALIZABLE.</div></div></div></div></blockquote><di=
v><div><div class=3D=22gmail=5Fsignature=22><br><div>I would suggest we t=
ake 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>=23=5BNotSerializable=5D</code>&nbsp;)&nbsp; that could be define=
d for any class (with <code>ZEND=5FACC=5FNOT=5FSERIALIZABLE</code>&nbsp; =
being automatically given this attribute)=3F It just seems to be a more h=
olistic approach that makes sense, rather than basing it on internal engi=
ne stuff and/or limiting it to internal objects.</div><br><div>Coogle</di=
v><br><br></div></div></div>
--66d9d658_6b8b4567_15a82--