Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128655
Precedence: list
MIME-Version: 1.0
Date: Mon, 08 Sep 2025 16:45:59 +0200
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Soft-Deprecate __sleep() and __wakeup()
In-Reply-To: <CAOWwgpk1Z_bns=Z55TqpYOBXvBGpurMfjTGPSgQ6Uf5QXfLOjg@mail.gmail.com>
References: <CAOWwgpk1Z_bns=Z55TqpYOBXvBGpurMfjTGPSgQ6Uf5QXfLOjg@mail.gmail.com>
Message-ID: <cddcbba0366184b616e34637b424645e@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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