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? >
