Le mer. 13 août 2025 à 12:47, Kamil Tekiela <tekiela...@gmail.com> a écrit :
> > > On Wed 13 Aug 2025, 13:44 Christoph M. Becker, <cmbecke...@gmx.de> wrote: > >> On 13.08.2025 at 11:00, Nicolas Grekas wrote: >> >> > Le ven. 8 août 2025 à 22:10, Gina P. Banyard <intern...@gpb.moe> a >> écrit : >> > >> >> The following proposals have been accepted: >> >> >> >> - Deprecate the __sleep() and __wakeup() magic methods (18 yay, 9 nay, >> >> 66.7%) >> > >> > I’d 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. >> For >> > example, in Symfony’s codebase there are numerous cases where switching >> > requires deep knowledge of PHP’s serialization format to maintain >> > 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’m concerned that the practical cost to the community may outweigh the >> > benefits, particularly since the rationale for removal seems, at least >> from >> > a user’s perspective, debatable. >> > >> > I don’t know if there is room to reconsider the deprecation, but 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? > 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
