Re: [RFC] Soft-Deprecate __sleep() and __wakeup()

Hi Am 2025-09-05 17:53, schrieb Nicolas Grekas:

Hello internals, Following the discussion that started at https://externals.io/message/128226#128456 I wrote this RFC to formalize our consensus on the topic. TL;DR, this is about converting the deprecation of __sleep and __wakeup to a documentation-based soft deprecation: https://wiki.php.net/rfc/soft-deprecate-sleep-wakeup

Thank you for the RFC. I have some comments: 1. I disagree with the phrasing that the RFC passed with a “narrow margin”. While it is technically true, that this is the narrowest margin for accepting an RFC, the necessary margins are already biased in favor of not accepting an RFC. That the RFC was accepted means that a significant majority of voters were in favor of the deprecation. I did not vote, since I did not have sufficient time to form an opinion on the RFC, but given the knowledge I've gained as part of the discussion I would now vote in favor of the RFC. 2. The examples are biased. As an example, the initial “User” example has a serialization hook that is completely useless. The other examples try to replicate __sleep()'s broken behavior exactly, which seems to be a relevant requirement in the real world for only a minority of users. 3. Similarly, I believe that the RFC *overstates* the cost of the deprecation. From my experience a majority of serialization hooks will just unconditionally throw an exception to prevent serialization. The truth is probably somewhere in the middle. 4. The RFC correctly acknowleges that __sleep() is broken with regard to private properties, but at the same time claims that the deprecation does not fix a “correctness problem”, which is a contradiction. 5. The serialization mechanism is also a security sensitive part of the language, the fewer moving parts there are, the better. Security is part of the motivation for me. ---------------------- That all said, as I've said before: I see that replacing __wakeup() by __unserialize() is non-trivial and I would be okay with deferring that one until we have some helper (e.g. **s**et_mangled_object_vars). But __sleep() can just go away. Best regards Tim Düsterhus