On Wednesday, 13 August 2025 at 12:47, Kamil Tekiela <tekiela...@gmail.com> wrote:
> 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? (Interrupting my holiday slightly to response to this) Yes you can, and this should be the way forward if needed. However, the problems seem to only be with __wakeup() rather than __sleep() so in any case I don't think a counterproposal should undeprecate the latter. Especially as Tim pointed out on the PR that it is basically impossible to properly implement __sleep() if inheritance is involved. [A] In any case, going from the analysis from Theodore, and me asking Damien to run an analysis and having a quick skim through them, the main "offenders" are Symfony transient dependencies. Thus, I'm not even sure a proposal to undeprecate it is warranted, as from what I've seen, many implementations as throwing, do validation on the resulting object, or unset() properties. And unless I'm misunderstanding, the concerns raised by Nicolas are things that need to be dealt with by frameworks, and possibly some libraries, rather than end-user code. (And on top of that, it doesn't look like Wordpress would have a hard time at all to support both __unserialize() and __wakeup().) I don't mind splitting the PR into 2 different ones, one for __sleep() and the other one for __wakeup(), but once again people are complaining that a 2/3 threshold is seemingly not enough when it is not necessarily an easy threshold to pass. Best regards, Gina P. Banyard [A] https://github.com/php/php-src/pull/19435#issuecomment-3180254434 >>
