Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128672
Precedence: list
MIME-Version: 1.0
Date: Thu, 11 Sep 2025 09:25:08 +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: <CAOWwgpntFNTjdJGwu_wdiTPeS5K1AcaGHO5Y4HGU8su3+9wPjQ@mail.gmail.com>
References: <CAOWwgpk1Z_bns=Z55TqpYOBXvBGpurMfjTGPSgQ6Uf5QXfLOjg@mail.gmail.com>
 <cddcbba0366184b616e34637b424645e@bastelstu.be>
 <CAOWwgpntFNTjdJGwu_wdiTPeS5K1AcaGHO5Y4HGU8su3+9wPjQ@mail.gmail.com>
Message-ID: <1bdd823c5ed2c5b8aba2d8f0dafd5ac2@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-10 18:17, schrieb Nicolas Grekas:
> 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.
>> 
> 
> The quantitative argument is not the only measure of the impact.
> The RFC explains why - qualitatively - the RFC will have a significant
> impact.
> For the quantitative part, we can talk forever before agreeing.

The product of both is the relevant metric. This appears to be a 
high-impact deprecation for a small amount of existing users. I believe 
that is less bad than a small-impact deprecation for a large amount of 
users. That's also why I voted against the driver-specific PDO 
constants, since the alternative is only available since the last 
version, giving folks little time for a natural migration. In this case, 
the alternative is available for quite some time already.

The impact to existing users is also not the only impact deprecating or 
not deprecating something will have. As an example, the RFC ignores the 
positive impact for folks that are newly writing some code by pointing 
them towards the “correct” solution. Something that is just in the 
documentation might as well not exist. Some of the documentation pages 
for functions I proposed to deprecate in past PHP versions are *full* of 
warnings (sometimes 3 of them), but folks *still* reach towards using 
those functions.

>> 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.
>> 
> 
> I'm not sure why you talk about throwing hooks. Those are not concerned 
> so
> that's orthogonal to the points made.

If the majority of serialization hooks will just throw, this means that 
the original RFC did not affect them, which then raises the question of 
whether or not claims such as “many users” are accurate.

>> 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.
>> 
> 
> I clarified this aspect in the RFC this way ("No technical urgency"
> section):
> 
>>  Some consider that __sleep() is broken because it is incompatible 
>> with
> nested private properties. Yet, this is more of a limitation rather 
> than
> something being broken: many use cases don't need access to private
> properties and are just fine with the method. When one needs to 
> overcome
> this limitation, one can migrate to __serialize, on an opt-in basis.

That is better, thank you. However “many use cases do not require 
private properties” is again making a claim that I'm not sure is 
supported by data. I don't have any better data, but:

- Using private properties is a best practice for encapsulation.
- When I serialize objects, I want to get the original data back out.

This suggests to me that supporting private properties properly cannot 
be an afterthought. Note that the issue with __sleep() is with private 
properties of parent and child classes. If inheritance doesn't get 
involved, __sleep() works just fine, but that case is also the case 
where migration to __serialize() is easy to do, since you the entire 
section (3) of the RFC doesn't apply.

In other words, the large migration complexity exists exactly in the 
cases that are not handled well by __sleep(), which I do not believe is 
coincidental! As a user you have a choice between continuing using 
__sleep() and breaking private properties or migrating to __serialize(), 
which will be painful once and then work will after that. To me the 
choice is clear: Doing the migration, since then I will not need to deal 
with the issues arising of broken inheritance for eternity.

>> 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.
>> 
> 
> We've added a note in the "Future scope" section, phrased like this:
> 
>> Consider dealing with __wakeup / __sleep separately as the impact 
>> might
> be specific to each one

Thank you.

Best regards
Tim Düsterhus