Re: [RFC] [VOTE] Deprecations for PHP 8.5
| From: | Christoph M. Becker | Date: | Wed, 13 Aug 2025 10:44:37 +0000 |
| Subject: | Re: [RFC] [VOTE] Deprecations for PHP 8.5 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-128458@lists.php.net to get a copy of this message | ||
On 13.08.2025 at 11:00, Nicolas Grekas wrote:
> Le ven. 8 août 2025 à 22:10, Gina P. Banyard <internals@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