Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128460 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id A86311A00BC for ; Wed, 13 Aug 2025 11:59:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1755086250; bh=D/yD6H7BVVyURXiDWg1U8QecyetvGipvVVwTh8wOoOw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XPiXdA6gHJGcC/AMK/s2shlNuKpP9WvSXgrN3Du4j8mDqHcoJICw1k5wyGkzrYXmF pCvubmo6/PvXEXSwmGio0UtajBiQ4gAnkR2IvqsbIXRk+VuNWu20tTn1znxiw8WxkC /9ooEhDsBuF0mj0aVsYDqo5GGlotYSz34NjnJ+vHL0oIlzcdTvaDPV8ETY7N1P+KWn 4BziWaM5HzXTEJEOEiXLIBk3E7Ns5xZgJTGph23ztjUecU5hPsMZ+rwcmk1HAhVWg6 REv+5yLv/yiUm21J6Cbtv+kKeK/otEh7lpmuPaQRGFrkS3iqueEvYZgoDXaV5HeCKV kLd+gSBr3IMLw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 2B09C180079 for ; Wed, 13 Aug 2025 11:57:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 13 Aug 2025 11:57:29 +0000 (UTC) Received: by mail-qk1-f181.google.com with SMTP id af79cd13be357-7e699c5b110so93978785a.1 for ; Wed, 13 Aug 2025 04:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1755086346; x=1755691146; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=l+tYWATcx5GK6OBbLRu8zokMHtY0l3VPwdzgF7avPR0=; b=kX6PUWQjWRVqtNHM3Plr+/zxHkt47z+o89IpETXdKbbcsKcxy0dEDOj6tpNYKmwbxG p0uKRLD6W7oj6CejB/TrsG78eXZNq8KMSIsjBO5HZH/XJqYAaNUOPAFVARIeP4l6kU0F oemq3W4kkxvwPmLsoFL+I9ZBJG3OovF5gmMdyZOKrj/rPeZ4yFik7j+/eJ7apTN6oxJp ZVZ+ljNh1l1gOpndzFMVY69riV0wvyP6nJrKPYeXPQh1moBF019EswvaftsQQsUGJNg9 7Qrok7O6W0ncZVIdVynAkCXqyAkLDlOHmwegucJnFdM4rBuoR61mucq4KXt6t1ZsyNg9 sqSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755086346; x=1755691146; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=l+tYWATcx5GK6OBbLRu8zokMHtY0l3VPwdzgF7avPR0=; b=U6FySuhPUX0Va6BN4vWJq1eL8KdahHoowdyyBVvkKNFej66w7ymrsNZH5u9JsLWt1c ZEdYI4wX9+WaOfFyji/EKPOvj64qdClz1zOmlWJvf5F+xkd0xN2gxTXCLEWh4Q1T7o2H EXiiOAgKon92mR7RKWYsAw9Gh3jP7lgZ007mFgugcfai42uKrUgaqtNU/wev8xFnA9ro ZmDxVSn0niDK2GsNYF3iBPdzoqoznVFrlDRq7F9mGcqjqYxhTGA/9ggXuTr0S3DdHD/3 GmKXEUMuJy269ztaO78LoRaQYI2xE0EHUCx/hdM83wXi1cT/crUiLxJmtu3qePktXhVs Nmlw== X-Forwarded-Encrypted: i=1; AJvYcCVaSQ//Mk/WSRdhgzfETxBm+EdIqyirgBR4yzqtLZ0HG7s1rNQ4tHx1r6O3ZMloGCGQtTgMNxhQQXY=@lists.php.net X-Gm-Message-State: AOJu0YyDiprx7i3gDtx0QceonCghBgT4l7M4jS2U/3nxkrliBGpx1Cg5 DR8r73nngdmQLuSFfIY0X3HZQ9uMIq9xjqP4lPU6Vay543XCv3JQGnzDWgEyMKmQBHKQ8hlRNl4 i/Qe634YaF7mrrHmBR2oxdLP1DZ1wjiw= X-Gm-Gg: ASbGncs/yqlgIQDXxqeWOzvh6HjPVefflCJc66mAtR0LpJrVI+6gJkgUN3h/uEa7YIz h5FJWSWpdsXdpT5VBEppxVG75uDDQIsSIaNc/gwZEv2tUqMQhItc0q5ziE9A/r8I8z9MI8Rwmrz HFXM5BDyyBQKnq5WR3lVc78d1IzwUHG84EEs9gDv3IdaIZSl3l79NZ5OgVLmZj5KhNenovS52i9 51gQaGjESu1UpboMzO4phUxJj416hai77O8/BccYQ== X-Google-Smtp-Source: AGHT+IG3Nhjmz3mLV054GFgqSpG9yreu9lL5f3bJTY+Rf8KLEb4Xl+BWOE5IQ8usE/rMdPmGG2jN0MtWoxt8zsbyVyQ= X-Received: by 2002:a05:620a:28d3:b0:7e3:3682:6dee with SMTP id af79cd13be357-7e866a762eamr238921585a.4.1755086346336; Wed, 13 Aug 2025 04:59:06 -0700 (PDT) Precedence: list list-help: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 13 Aug 2025 13:58:54 +0200 X-Gm-Features: Ac12FXxsgHR_Fpf3cVUHE9eIRd1uKCKPQ5deOGj2piUuTdc0_pKYOIbu6__-5aA Message-ID: Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecations for PHP 8.5 To: Kamil Tekiela Cc: "Christoph M. Becker" , "Gina P. Banyard" , PHP internals Content-Type: multipart/alternative; boundary="000000000000393f94063c3de28a" From: nicolas.grekas+php@gmail.com (Nicolas Grekas) --000000000000393f94063c3de28a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mer. 13 ao=C3=BBt 2025 =C3=A0 12:47, Kamil Tekiela a =C3=A9crit : > > > On Wed 13 Aug 2025, 13:44 Christoph M. Becker, 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 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 deprecat= e >> __sleep() >> > and __wakeup(). >> > >> > While I understand the intention behind moving toward __serialize() an= d >> > __unserialize(), in practice the migration path is often non-trivial. >> For >> > example, in Symfony=E2=80=99s codebase there are numerous cases where = switching >> > requires deep knowledge of PHP=E2=80=99s serialization format to maint= ain >> > compatibility with existing payloads. This is essential so that update= d >> > 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 out= weigh 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, b= ut 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] >> >> Christoph >> > > Can we propose to undeprecate it before the feature freeze? > I wish we had some process to revert that decision. Now is the less costly time to do it, even if it's already late. The discussion period failed to raise the points made by Jakub in the PR ( https://github.com/php/php-src/pull/19435) and failed a serious impact analysis IMHO. This should be enough to raise a flag and allow us to reconsider. I wonder if people that voted in favor of deprecating __sleep/wakeup would still vote the same now? Nicolas --000000000000393f94063c3de28a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le=C2=A0mer. 13= ao=C3=BBt 2025 =C3=A0=C2=A012:47, Kamil Tekiela <tekiela246@gmail.com> a =C3=A9crit=C2=A0:
<= br>
On = Wed 13 Aug 2025, 13:44 Christoph M. Becker, <cmbecker69@gmx.de> wrote:
On 13.08.2025 at 11:00, Nicola= s Grekas wrote:

> Le ven. 8 ao=C3=BBt 2025 =C3=A0 22:10, Gina P. Banyard <internals@g= pb.moe> 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 deprecat= e __sleep()
> and __wakeup().
>
> While I understand the intention behind moving toward __serialize() an= d
> __unserialize(), in practice the migration path is often non-trivial. = For
> example, in Symfony=E2=80=99s codebase there are numerous cases where = switching
> requires deep knowledge of PHP=E2=80=99s serialization format to maint= ain
> compatibility with existing payloads. This is essential so that update= d
> 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 c= ases.
> I=E2=80=99m concerned that the practical cost to the community may out= weigh 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, b= ut 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().=C2=A0 Even the New custom object<= br> 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/cust= om_object_serialization>

Christoph

Can we propose to undeprecate it before the feature freeze?
=

I wish we had some process to revert= that decision. Now is the less costly time to do it, even if it's alre= ady late.
The discussion period failed to raise the points made b= y Jakub in the PR (ht= tps://github.com/php/php-src/pull/19435) and failed a serious impact an= alysis IMHO.
This should be enough to raise a flag and allow us t= o reconsider.
I wonder if people that voted=C2=A0in favor of depr= ecating __sleep/wakeup would still vote the same now?

<= div>Nicolas --000000000000393f94063c3de28a--