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
