Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128459
Precedence: list
MIME-Version: 1.0
References: <bHOrFNomgRBQ5FCRh1oK4cXbtPudF22WfgTqtqUIO7SsTMRulRakqBgOvRRFfm8xdDNYFr0AIV6NZ_r5p_h4E5Nz-LZLwZoBw0S9J9NALcA=@gpb.moe>
 <Yy5Yk-VCtT880CdOOXp4RO1DsMnUmDP0n2JJ59nRBlQRTeTv3zQo3ERkMpQkwukArEdpCX7P49_oc9DZbxa0ZfzgO4Q4Z_KrCYpgIgLS7PM=@gpb.moe>
 <CAOWwgpkO6yKrp5oosfRXW0bcxc4-5FEPf4kOuMVBtjqb3PshDw@mail.gmail.com> <b2dcca97-7bc3-43f3-b8ac-082966e5dfb7@gmx.de>
In-Reply-To: <b2dcca97-7bc3-43f3-b8ac-082966e5dfb7@gmx.de>
Date: Wed, 13 Aug 2025 13:47:13 +0300
Message-ID: <CAGBsUreXOKpQJjxmNuYsEiSF6hm8usvacSGLW8OZ2779ux1UMg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.5
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: Nicolas Grekas <nicolas.grekas+php@gmail.com>, "Gina P. Banyard" <internals@gpb.moe>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ecb24b063c3ce19b"
From: tekiela246@gmail.com (Kamil Tekiela)

--000000000000ecb24b063c3ce19b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed 13 Aug 2025, 13:44 Christoph M. Becker, <cmbecker69@gmx.de> wrote:

> On 13.08.2025 at 11:00, Nicolas Grekas wrote:
>
> > Le ven. 8 ao=C3=BBt 2025 =C3=A0 22:10, Gina P. Banyard <internals@gpb.m=
oe> a
> =C3=A9crit :
> >
> >> The following proposals have been accepted:
> >>
> >> - Deprecate the __sleep() and __wakeup() magic methods (18 yay, 9 nay,
> >> 66.7%)
> >
> > I=E2=80=99d like to raise some concerns about the decision to deprecate=
 __sleep()
> > and __wakeup().
> >
> > While I understand the intention behind moving toward __serialize() and
> > __unserialize(), in practice the migration path is often non-trivial. F=
or
> > example, in Symfony=E2=80=99s codebase there are numerous cases where s=
witching
> > requires deep knowledge of PHP=E2=80=99s serialization format to mainta=
in
> > compatibility with existing payloads. This is essential so that updated
> > applications can still communicate with older versions.
> >
> > For many projects, this will be a significant burden, especially given
> that
> > __sleep() and __wakeup() have historically worked well for these use
> cases.
> > I=E2=80=99m concerned that the practical cost to the community may outw=
eigh the
> > benefits, particularly since the rationale for removal seems, at least
> from
> > a user=E2=80=99s perspective, debatable.
> >
> > I don=E2=80=99t know if there is room to reconsider the deprecation, bu=
t I wanted
> > to share this perspective from the field.
>
> Frankly, I do not quite understand why it has even been suggested (so
> early) to deprecate __sleep()/__wakeup().  Even the New custom object
> serialization mechanism RFC[1] acknowledged that this mechanism is *not*
> fundamentally broken, but only somewhat limited, and that:
>
> | There is no particular pressing need to phase out __sleep() and
> | __wakeup().
>
> However, I'm afraid that ship has sailed.
>
> [1] <https://wiki.php.net/rfc/custom_object_serialization>
>
> Christoph
>

Can we propose to undeprecate it before the feature freeze?

>

--000000000000ecb24b063c3ce19b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai=
ner"><div dir=3D"ltr" class=3D"gmail_attr">On Wed 13 Aug 2025, 13:44 Christ=
oph M. Becker, &lt;<a href=3D"mailto:cmbecker69@gmx.de">cmbecker69@gmx.de</=
a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 13.08.2025 at 11:0=
0, Nicolas Grekas wrote:<br>
<br>
&gt; Le ven. 8 ao=C3=BBt 2025 =C3=A0 22:10, Gina P. Banyard &lt;internals@g=
pb.moe&gt; a =C3=A9crit :<br>
&gt; <br>
&gt;&gt; The following proposals have been accepted:<br>
&gt;&gt;<br>
&gt;&gt; - Deprecate the __sleep() and __wakeup() magic methods (18 yay, 9 =
nay,<br>
&gt;&gt; 66.7%)<br>
&gt; <br>
&gt; I=E2=80=99d like to raise some concerns about the decision to deprecat=
e __sleep()<br>
&gt; and __wakeup().<br>
&gt; <br>
&gt; While I understand the intention behind moving toward __serialize() an=
d<br>
&gt; __unserialize(), in practice the migration path is often non-trivial. =
For<br>
&gt; example, in Symfony=E2=80=99s codebase there are numerous cases where =
switching<br>
&gt; requires deep knowledge of PHP=E2=80=99s serialization format to maint=
ain<br>
&gt; compatibility with existing payloads. This is essential so that update=
d<br>
&gt; applications can still communicate with older versions.<br>
&gt; <br>
&gt; For many projects, this will be a significant burden, especially given=
 that<br>
&gt; __sleep() and __wakeup() have historically worked well for these use c=
ases.<br>
&gt; I=E2=80=99m concerned that the practical cost to the community may out=
weigh the<br>
&gt; benefits, particularly since the rationale for removal seems, at least=
 from<br>
&gt; a user=E2=80=99s perspective, debatable.<br>
&gt; <br>
&gt; I don=E2=80=99t know if there is room to reconsider the deprecation, b=
ut I wanted<br>
&gt; to share this perspective from the field.<br>
<br>
Frankly, I do not quite understand why it has even been suggested (so<br>
early) to deprecate __sleep()/__wakeup().=C2=A0 Even the New custom object<=
br>
serialization mechanism RFC[1] acknowledged that this mechanism is *not*<br=
>
fundamentally broken, but only somewhat limited, and that:<br>
<br>
| There is no particular pressing need to phase out __sleep() and<br>
| __wakeup().<br>
<br>
However, I&#39;m afraid that ship has sailed.<br>
<br>
[1] &lt;<a href=3D"https://wiki.php.net/rfc/custom_object_serialization" re=
l=3D"noreferrer noreferrer" target=3D"_blank">https://wiki.php.net/rfc/cust=
om_object_serialization</a>&gt;<br>
<br>
Christoph<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Can we propose to undeprecate it before the feature freeze?</div>=
<div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
</blockquote></div></div></div>

--000000000000ecb24b063c3ce19b--