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
