Re: [RFC] [VOTE] Deprecations for PHP 8.5

From: Date: Wed, 13 Aug 2025 10:44:37 +0000
Subject: Re: [RFC] [VOTE] Deprecations for PHP 8.5
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-128458@lists.php.net to get a copy of this message
On 13.08.2025 at 11:00, Nicolas Grekas wrote: > Le ven. 8 août 2025 à 22:10, Gina P. Banyard <internals@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

« previous php.internals (#128458) next »