# [RFC] [VOTE] Deprecations for PHP 8.5 - Thread: https://externals.io/message/128226 - Original archive: https://news-web.php.net/php.internals/128226 - Started by Gina P. Banyard on 2025-07-25T12:56:40+00:00 - Messages: 17 - RFC: Soft-Deprecate __sleep() and __wakeup() (Implemented (PHP 8.5)) — https://externals.io/rfc/soft-deprecate-sleep-wakeup.md - RFC: Deprecations for PHP 8.5 (Implemented (PHP 8.5)) — https://externals.io/rfc/deprecations_php_8_5.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #128226 — Gina P. Banyard — 2025-07-25T12:56:40+00:00 URL: https://externals.io/message/128226#128226 Hello internals, As Tim announced a few days ago, I've opened the votes for the deprecations: https://wiki.php.net/rfc/deprecations_php_8_5 Please remember that the wiki is only capable to handle a single vote at a time, so please submit each vote you intend on casting individually. Best regards, Gina P. Banyard --- ## #128443 — Gina P. Banyard — 2025-08-08T20:07:19+00:00 URL: https://externals.io/message/128226#128443 · In reply to: #128226 > Hello internals, > > As Tim announced a few days ago, I've opened the votes for the deprecations: > https://wiki.php.net/rfc/deprecations_php_8_5 > > Please remember that the wiki is only capable to handle a single vote at a time, > so please submit each vote you intend on casting individually. > Hello internals, After two weeks of voting, I closed the votes of the "Deprecations for PHP 8.5" RFC at 19:45 UTC. The following proposals have been accepted: - Deprecate semicolon after case in switch statement (22 yay, 10 nay, 68.8%) - Deprecate non-standard cast names (32 yay, 0 nay, 100%) - Deprecate backticks as an alias for shell_exec (21 yay, 8 nay, 72.4%) - Deprecate the __sleep() and __wakeup() magic methods (18 yay, 9 nay, 66.7%) - Deprecate using values null as an array offset and when calling `array_key_exists()` (25 yay, 3 nay, 89.3%) - Deprecate __debugInfo() returning null (22 yay, 5 nay, 81.5%) - Deprecate constant redeclaration (31 yay, 0 nay, 100%) - Deprecate closure binding issues (29 yay, 0 nay, 100%) - Enact follow-up phase of the "Path to Saner Increment/Decrement operators" RFC (23 yay, 4 nay, 85.2%) - Deprecate the report_memleaks INI directive (23 yay, 2 nay, 92.0%) - Deprecate the register_argc_argv INI directive (27 yay, 0 nay, 100%) - Remove disable_classes INI setting (26 yay, 0 nay, 100%) - Deprecate Reflection*::setAccessible() (24 yay, 0 nay, 100%) - Deprecate ReflectionClass::getConstant() for missing constants (25 yay, 0 nay, 100%) - Deprecate ReflectionProperty::getDefaultValue() for properties without default values (21 yay, 2 nay, 89.5%) - Deprecate ArrayObject and ArrayIterator with objects (26 yay, 0 nay, 100%) - Deprecate SplObjectStorage::contains(), SplObjectStorage::attach(), and SplObjectStorage::detach() (17 yay, 2 nay, 89.5%) - Deprecate passing `spl_autoload_call()` to `spl_autoload_unregister()` (23 yay, 0 nay, 100%) - Deprecate the $exclude_disabled parameter of `get_defined_functions()` (23 yay, 0 nay, 100%) - Deprecate passing null to `readdir()`, `rewinddir()`, and `closedir()` (24 yay, 3 nay, 88.9%) - Deprecate passing string which are not one byte long to `ord()` (20 yay, 4 nay, 83.3%) - Deprecate passing integers outside the interval [0, 255] to `chr()` (21 yay, 1 nay, 95.5%) - Formally deprecate socket_set_timeout (22 yay, 0 nay, 100%) - Deprecate the $http_response_header predefined variable (22 yay, 2 nay, 91.7%) - [ODBC] Remove flags for building against specific drivers directly (16 yay, 0 nay, 100%) - Remove support for older ODBC versions (15 yay, 0 nay, 100%) - Deprecate PDO's 'uri:' scheme (22 yay, 0 nay, 100%) - Deprecate driver specific PDO constants and methods (17 yay, 6 nay, 73.9%) - Deprecate Pdo\Pgsql constants related to statement transaction state (17 yay, 0 nay, 100%) - Deprecate `finfo_close()` (24 yay, 2 nay, 92.3%) - Deprecate `xml_parser_free()` (22 yay, 2 nay, 91.7%) - Deprecate `curl_close()` (23 yay, 3 nay, 88.5%) - Deprecate `curl_share_close()` (23 yay, 3 nay, 88.5%) - Deprecate imagedestroy() (23 yay, 2 nay, 92.0%) - Deprecate key_length parameter of `openssl_pkey_derive()` (24 yay, 0 nay, 100%) - Deprecate intl.error_level INI setting (22 yay, 0 nay, 100%) - Formally deprecate `mysqli_execute()` (22 yay, 0 nay, 100%) - Deprecate building ext/ldap against Oracle LDAP (19 yay, 0 nay, 100%) - Deprecate the $context parameter for `finfo_buffer()` (24 yay, 0 nay, 100%) - Deprecate DATE_RFC7231 and DateTimeInterface::RFC7231 (22 yay, 0 nay, 100%) And the following proposals have been rejected: - Deprecate attributes applying to multiple class properties/constants (5 yay, 19 nay, 20.8%) - Deprecate ReflectionParameter::allowsNull() (9 yay, 10 nay, 47.4%) - Deprecate non-canonical type names for `settype()` (8 yay, 10 nay, 44.4%) - Deprecate `FILTER_DEFAULT` constant (12 yay, 10 nay, 54.5%) - Make $filter parameter mandatory for filter_*() functions (9 yay, 10 nay, 47.4%) - Deprecate PDO::ERRMODE_WARNING error mode (8 yay, 12 nay, 40.0%) Thank you to everyone that has voted and participated in the discussions. Best regards, Gina P. Banyard --- ## #128456 — Nicolas Grekas — 2025-08-13T09:00:29+00:00 URL: https://externals.io/message/128226#128456 · In reply to: #128443 Le ven. 8 août 2025 à 22:10, Gina P. Banyard a écrit : > On Friday, 25 July 2025 at 13:56, Gina P. Banyard > wrote: > > > […] > deprecations: > > […] > a time, > > […] > > Hello internals, > > After two weeks of voting, I closed the votes of the "Deprecations for PHP > 8.5" RFC at 19:45 UTC. > > The following proposals have been accepted: > > - Deprecate semicolon after case in switch statement (22 yay, 10 nay, > 68.8%) > - Deprecate non-standard cast names (32 yay, 0 nay, 100%) > - Deprecate backticks as an alias for shell_exec (21 yay, 8 nay, 72.4%) > - Deprecate the __sleep() and __wakeup() magic methods (18 yay, 9 nay, > 66.7%) > - Deprecate using values null as an array offset and when calling > `array_key_exists()` (25 yay, 3 nay, 89.3%) > - Deprecate __debugInfo() returning null (22 yay, 5 nay, 81.5%) > - Deprecate constant redeclaration (31 yay, 0 nay, 100%) > - Deprecate closure binding issues (29 yay, 0 nay, 100%) > - Enact follow-up phase of the "Path to Saner Increment/Decrement > operators" RFC (23 yay, 4 nay, 85.2%) > - Deprecate the report_memleaks INI directive (23 yay, 2 nay, 92.0%) > - Deprecate the register_argc_argv INI directive (27 yay, 0 nay, 100%) > - Remove disable_classes INI setting (26 yay, 0 nay, 100%) > - Deprecate Reflection*::setAccessible() (24 yay, 0 nay, 100%) > - Deprecate ReflectionClass::getConstant() for missing constants (25 yay, > 0 nay, 100%) > - Deprecate ReflectionProperty::getDefaultValue() for properties without > default values (21 yay, 2 nay, 89.5%) > - Deprecate ArrayObject and ArrayIterator with objects (26 yay, 0 nay, > 100%) > - Deprecate SplObjectStorage::contains(), SplObjectStorage::attach(), and > SplObjectStorage::detach() (17 yay, 2 nay, 89.5%) > - Deprecate passing `spl_autoload_call()` to `spl_autoload_unregister()` (23 > yay, 0 nay, 100%) > - Deprecate the $exclude_disabled parameter of `get_defined_functions()` (23 > yay, 0 nay, 100%) > - Deprecate passing null to `readdir()`, `rewinddir()`, and `closedir()` (24 > yay, 3 nay, 88.9%) > - Deprecate passing string which are not one byte long to `ord()` (20 yay, 4 > nay, 83.3%) > - Deprecate passing integers outside the interval [0, 255] to `chr()` (21 > yay, 1 nay, 95.5%) > - Formally deprecate socket_set_timeout (22 yay, 0 nay, 100%) > - Deprecate the $http_response_header predefined variable (22 yay, 2 nay, > 91.7%) > - [ODBC] Remove flags for building against specific drivers directly (16 > yay, 0 nay, 100%) > - Remove support for older ODBC versions (15 yay, 0 nay, 100%) > - Deprecate PDO's 'uri:' scheme (22 yay, 0 nay, 100%) > - Deprecate driver specific PDO constants and methods (17 yay, 6 nay, > 73.9%) > - Deprecate Pdo\Pgsql constants related to statement transaction state (17 > yay, 0 nay, 100%) > - Deprecate `finfo_close()` (24 yay, 2 nay, 92.3%) > - Deprecate `xml_parser_free()` (22 yay, 2 nay, 91.7%) > - Deprecate `curl_close()` (23 yay, 3 nay, 88.5%) > - Deprecate `curl_share_close()` (23 yay, 3 nay, 88.5%) > - Deprecate imagedestroy() (23 yay, 2 nay, 92.0%) > - Deprecate key_length parameter of `openssl_pkey_derive()` (24 yay, 0 nay, > 100%) > - Deprecate intl.error_level INI setting (22 yay, 0 nay, 100%) > - Formally deprecate `mysqli_execute()` (22 yay, 0 nay, 100%) > - Deprecate building ext/ldap against Oracle LDAP (19 yay, 0 nay, 100%) > - Deprecate the $context parameter for `finfo_buffer()` (24 yay, 0 nay, 100%) > - Deprecate DATE_RFC7231 and DateTimeInterface::RFC7231 (22 yay, 0 nay, > 100%) > > And the following proposals have been rejected: > > - Deprecate attributes applying to multiple class properties/constants (5 > yay, 19 nay, 20.8%) > - Deprecate ReflectionParameter::allowsNull() (9 yay, 10 nay, 47.4%) > - Deprecate non-canonical type names for `settype()` (8 yay, 10 nay, 44.4%) > - Deprecate `FILTER_DEFAULT` constant (12 yay, 10 nay, 54.5%) > - Make $filter parameter mandatory for filter_*() functions (9 yay, 10 > nay, 47.4%) > - Deprecate PDO::ERRMODE_WARNING error mode (8 yay, 12 nay, 40.0%) > > Thank you to everyone that has voted and participated in the discussions. > > Best regards, > > Gina P. Banyard > 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. Cheers, Nicolas --- ## #128457 — Jakub Zelenka — 2025-08-13T09:16:05+00:00 URL: https://externals.io/message/128226#128457 · In reply to: #128456 On Wed, Aug 13, 2025 at 11:03 AM Nicolas Grekas < nicolas.grekas+php@gmail.com> wrote: > > > Le ven. 8 août 2025 à 22:10, Gina P. Banyard a écrit : > > > […] > > 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. > > Fully agree and this is exactly what I noted in https://github.com/php/php-src/pull/19435 . I think this RFC was very poor in showing the effort that is needed for migration as it was represented like a trivial thing. Kind regards Jakub --- ## #128458 — Christoph M. Becker — 2025-08-13T10:44:37+00:00 URL: https://externals.io/message/128226#128458 · In reply to: #128456 > Le ven. 8 août 2025 à 22:10, Gina P. Banyard a écrit : > > > […] > > 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] Christoph --- ## #128459 — Kamil Tekiela — 2025-08-13T10:47:13+00:00 URL: https://externals.io/message/128226#128459 · In reply to: #128458 > > > > […] > écrit : > > […] > that > > […] > cases. > > […] > from > > […] > > 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] > > Christoph > Can we propose to undeprecate it before the feature freeze? --- ## #128460 — Nicolas Grekas — 2025-08-13T11:58:54+00:00 URL: https://externals.io/message/128226#128460 · In reply to: #128459 Le mer. 13 août 2025 à 12:47, Kamil Tekiela a écrit : > > > > > > […] > > Can we propose to undeprecate it before the feature freeze? > I wish we had some process to revert that decision. Now is the less costly time to do it, even if it's already late. The discussion period failed to raise the points made by Jakub in the PR ( https://github.com/php/php-src/pull/19435) and failed a serious impact analysis IMHO. This should be enough to raise a flag and allow us to reconsider. I wonder if people that voted in favor of deprecating __sleep/wakeup would still vote the same now? Nicolas --- ## #128461 — tim@bastelstu.be — 2025-08-13T12:33:39+00:00 URL: https://externals.io/message/128226#128461 · In reply to: #128460 Hi > I wish we had some process to revert that decision. Now is the less costly > time to do it, even if it's already late. There is always the option of ”not implementing” the decision. Reverting would mean another RFC that would also require a 2/3 majority. > The discussion period failed to raise the points made by Jakub in the PR ( > https://github.com/php/php-src/pull/19435) and failed a serious impact > analysis IMHO. > This should be enough to raise a flag and allow us to reconsider. > I wonder if people that voted in favor of deprecating __sleep/wakeup would > still vote the same now? I already participated in the PR discussion and having slept over it, I think it would be helpful to consider both __sleep() and __wakeup() separately in this discussion of whether or not to actually follow through with doing the deprecation. As I've mentioned in the PR, `__sleep()` is actually broken when inheritance is involved and there's also a trivial way to implement `__serialize()` while preserving compatibility: public function __serialize() { return get_mangled_object_vars($this); } So while this one might result in some amount of migration work, it's reasonably easy to do. `__wakeup()` on the other hand is not broken and migrating to `__unserialize()` is non-trivial. So deprecating `__sleep()` with PHP 8.5 still makes sense to me. For `__wakeup()` I don't have a strong opinion either way and I've also intentionally abstained from voting on this deprecation. Best regards Tim Düsterhus --- ## #128465 — Paul M. Jones — 2025-08-13T15:01:31+00:00 URL: https://externals.io/message/128226#128465 · In reply to: #128459 Hi all, > Can we propose to undeprecate it before the feature freeze? When one part of the Attributes v2 RFC did not work out as some wanted, there was a re-vote: - https://wiki.php.net/rfc/attributes_v2 - https://wiki.php.net/rfc/shorter_attribute_syntax_change So there's precedent for this kind of thing. -- pmj --- ## #128466 — Nicolas Grekas — 2025-08-13T15:34:02+00:00 URL: https://externals.io/message/128226#128466 · In reply to: #128461 Le mer. 13 août 2025 à 14:33, Tim Düsterhus a écrit : > Hi > > > > […] > costly > > […] > > There is always the option of ”not implementing” the decision. Reverting > would mean another RFC that would also require a 2/3 majority. > I'm happy to do it this way if that's the consensus. > > […] > ( > > […] > would > > […] > > I already participated in the PR discussion and having slept over it, I > think it would be helpful to consider both __sleep() and __wakeup() > separately in this discussion of whether or not to actually follow > through with doing the deprecation. > > As I've mentioned in the PR, `__sleep()` is actually broken when > inheritance is involved and there's also a trivial way to implement > `__serialize()` while preserving compatibility: > > public function __serialize() { > return get_mangled_object_vars($this); > } > Well, the way to introduce __serialize while maintaining compatibility with both child classes and existing payloads is to copy/paste the same boilerplate over and over: public function __serialize(): array { $data = []; foreach ($this->__sleep() as $key) { $data[$key] = $this->$key; } return $data; } And then, this has exactly the same issue regarding private properties, without any better way since this has to call __sleep to account for child classes. This is just moving the concern elsewhere without any benefit. On their side, child classes that do have an issue with private properties can already implement __serialize on their side, there's nothing to fix here: __sleep works well, and there's already an upgrade path when it's not enough. > So while this one might result in some amount of migration work, it's > reasonably easy to do. > > `__wakeup()` on the other hand is not broken and migrating to > `__unserialize()` is non-trivial. > > So deprecating `__sleep()` with PHP 8.5 still makes sense to me. For > `__wakeup()` I don't have a strong opinion either way and I've also > intentionally abstained from voting on this deprecation. > implementing __unserialize to satisfy a proper upgrade path for payload and child classes might be done this way: public function __unserialize(array $data): void { foreach ($data as $key => $value) { $this->{("\0" === $key[0] ?? '') ? substr($key, 1 + strrpos($key, "\0")) : $key} = $value; } $this->__wakeup(); } Again, this doesn't work with private properties. The previous code was better and safer, and contained less boilerplate. I made a draft PR for SYmfony here: https://github.com/symfony/symfony/pull/61407 I'm not sure the implementation is correct yet. That's just to show the kind of impact this could have. Deprecating only sleep and not wakeup would at least fix the complexity of the __unserialize replacement. But then, this would fail the purpose of the RFC, which was to get rid of sleep/wakeup altogether. This deprecation is a net loss on every aspect. Nicolas --- ## #128467 — Nicolas Grekas — 2025-08-13T16:36:22+00:00 URL: https://externals.io/message/128226#128467 · In reply to: #128466 Le mer. 13 août 2025 à 17:34, Nicolas Grekas a écrit : > > > Le mer. 13 août 2025 à 14:33, Tim Düsterhus a écrit : > > > […] > > I'm happy to do it this way if that's the consensus. > > > > > […] > > Well, the way to introduce __serialize while maintaining compatibility > with both child classes and existing payloads is to copy/paste the same > boilerplate over and over: > > public function __serialize(): array > { > $data = []; > foreach ($this->__sleep() as $key) { > $data[$key] = $this->$key; > } > return $data; > } > > And then, this has exactly the same issue regarding private properties, > without any better way since this has to call __sleep to account for child > classes. > This is just moving the concern elsewhere without any benefit. > On their side, child classes that do have an issue with private properties > can already implement __serialize on their side, there's nothing to fix > here: __sleep works well, and there's already an upgrade path when it's not > enough. > > > > > […] > > implementing __unserialize to satisfy a proper upgrade path for payload > and child classes might be done this way: > > public function __unserialize(array $data): void > { > foreach ($data as $key => $value) { > $this->{("\0" === $key[0] ?? '') ? substr($key, 1 + > strrpos($key, "\0")) : $key} = $value; > } > $this->__wakeup(); > } > > Again, this doesn't work with private properties. > > The previous code was better and safer, and contained less boilerplate. > > I made a draft PR for SYmfony here: > https://github.com/symfony/symfony/pull/61407 > I'm not sure the implementation is correct yet. > That's just to show the kind of impact this could have. > > Deprecating only sleep and not wakeup would at least fix the complexity of > the __unserialize replacement. > But then, this would fail the purpose of the RFC, which was to get rid of > sleep/wakeup altogether. > > This deprecation is a net loss on every aspect. > > Nicolas > Here is the result of my investigation; the kind code that everybody that cares about FC/BC for child classes and payloads will have to use (above PR is up to date): public function __serialize(): array { $data = []; foreach ($this->__sleep() as $key) { try { if (($r = new \ReflectionProperty($this, $key))->isInitialized($this)) { $data[$key] = $r->getValue($this); } } catch (\ReflectionException) { $data[$key] = $this->$key; } } return $data; } public function __unserialize(array $data): void { \Closure::bind(function ($data) { foreach ($data as $key => $value) { $this->{("\0" === $key[0] ?? '') ? substr($key, 1 + strrpos($key, "\0")) : $key} = $value; } $this->__wakeup(); }, $this, static::class)($data); } --- ## #128468 — Larry Garfield — 2025-08-13T16:54:25+00:00 URL: https://externals.io/message/128226#128468 · In reply to: #128467 > Le mer. 13 août 2025 à 17:34, Nicolas Grekas > > > a écrit : > > […] > > Here is the result of my investigation; the kind code that everybody > that cares about FC/BC for child classes and payloads will have to use > (above PR is up to date): > > public function __serialize(): array > { > $data = []; > foreach ($this->__sleep() as $key) { > try { > if (($r = new \ReflectionProperty($this, > $key))->isInitialized($this)) { > $data[$key] = $r->getValue($this); > } > } catch (\ReflectionException) { > $data[$key] = $this->$key; > } > } > return $data; > } > public function __unserialize(array $data): void > { > \Closure::bind(function ($data) { > foreach ($data as $key => $value) { > $this->{("\0" === $key[0] ?? '') ? substr($key, 1 + > strrpos($key, "\0")) : $key} = $value; > } > $this->__wakeup(); > }, $this, static::class)($data); > } Eew. :-) I support the goal of having only one serialization process for devs to think about, but it does need to have a clear and graceful transition for existing code. The above code does not strike me as "clear and graceful transition." From the RFC: > Having multiple serializations methods which can be superseded by newer methods is somewhat confusing and add unnecessary complexity to the language. I agree, which is why I voted Yes on that part. > Because the __serialize()/__unserialize() mechanism is a straight up improvement over __sleep()/__wakeup() we propose to deprecate the latter in favour of the former. This claim now appears to be incorrect, given Nicolas' investigation. (Ie, it's not a straight up improvement, nor a drop-in replacement.) I would be in favor of holding off implementing this deprecation until a better transition process is found, and/or an RFC to reverse it. (I defer to the RMs on the process they want to follow.) (And I think this does lend still more weight to Juliette's frequent request for more robust impact analysis for deprecations. Not because deprecations are bad, but because we should know what the impact is so we know how to mitigate it effectively.) --Larry Garfield --- ## #128469 — Theodore Brown — 2025-08-13T22:20:54+00:00 URL: https://externals.io/message/128226#128469 · In reply to: #128468 > (And I think this does lend still more weight to Juliette's frequent request for more > robust impact analysis for deprecations. Not because deprecations are bad, but because > we should know what the impact is so we know how to mitigate it effectively.) I analyzed the top 1500 Composer packages to find and categorize usages of the `__sleep` and `__wakeup` methods. There are a total of 250 `__sleep` methods and 259 `__wakeup` methods in these packages (509 total). Of these, 108 are empty methods containing no code. Most of these are stubs in the jetbrains\phpstorm-stubs package. Another 152 of the methods contain only a single throw statement. This leaves 160 `__sleep` methods and 89 `__wakeup` methods (249 total) which do something else. 150 of these (over 60%) exist in just 9 packages: * doctrine\orm - 14 * drupal\core - 38 * laminas\laminas-server - 7 * maatwebsite\excel - 7 * magento\zend-db - 7 * pdepend\pdepend - 31 * roots\wordpress-no-content - 6 * symfony\mime - 8 * symfony\symfony - 32 Outside of the above packages, `__sleep` and `__wakup` methods generally seem to be few and far between. I created a Google Sheet to view the per-package statistics: https://docs.google.com/spreadsheets/d/1i7GINJdTjXk4lj012vwd7ipZTxuucduYh-JyYm6V6Y8/edit?usp=sharing The raw code for each `__sleep` and `__wakeup` method can be viewed here: https://gist.github.com/theodorejb/965633b9787475dfe64cc53dc941bc49 Kind regards, Theodore --- ## #128470 — Matteo Beccati — 2025-08-14T06:35:46+00:00 URL: https://externals.io/message/128226#128470 · In reply to: #128468 Hi, Il 13/08/2025 18:54, Larry Garfield ha scritto: > I would be in favor of holding off implementing this deprecation until a better transition process is found, and/or an RFC to reverse it. (I defer to the RMs on the process they want to follow.) > > (And I think this does lend still more weight to Juliette's frequent request for more robust impact analysis for deprecations. Not because deprecations are bad, but because we should know what the impact is so we know how to mitigate it effectively.) +1 Cheers -- Matteo --- ## #128475 — Theodore Brown — 2025-08-14T20:54:58+00:00 URL: https://externals.io/message/128226#128475 · In reply to: #128469 > I analyzed the top 1500 Composer packages to find and categorize usages of the > `__sleep` and `__wakeup` methods. There are a total of 250 `__sleep` methods > and 259 `__wakeup` methods in these packages (509 total). > > Of these, 108 are empty methods containing no code. Most of these are stubs > in the jetbrains\phpstorm-stubs package. > > Another 152 of the methods contain only a single throw statement. > > This leaves 160 `__sleep` methods and 89 `__wakeup` methods (249 total) which do > something else. 150 of these (over 60%) exist in just 9 packages: > > * doctrine\orm - 14 > * drupal\core - 38 > * laminas\laminas-server - 7 > * maatwebsite\excel - 7 > * magento\zend-db - 7 > * pdepend\pdepend - 31 > * roots\wordpress-no-content - 6 > * symfony\mime - 8 > * symfony\symfony - 32 > > Outside of the above packages, `__sleep` and `__wakup` methods generally seem to > be few and far between. > > I created a Google Sheet to view the per-package statistics: > https://docs.google.com/spreadsheets/d/1i7GINJdTjXk4lj012vwd7ipZTxuucduYh-JyYm6V6Y8/edit?usp=sharing > > The raw code for each `__sleep` and `__wakeup` method can be viewed here: > https://gist.github.com/theodorejb/965633b9787475dfe64cc53dc941bc49 Update: it looks like nearly all the Symfony usages have already been fixed for Symfony 8. I re-downloaded and analyzed the top 1500 packages again this afternoon, and now there are a total of 159 `__sleep` methods and 207 `__wakeup` methods in 65 distinct packages, a significant drop from when I did the analysis yesterday. 107 of the methods are empty, and 65 only contain a single throw statement. Over 62% of the remaining methods exist in just 9 packages: * doctrine\orm - 14 * drupal\core - 36 * johnpbloch\wordpress-core - 6 * laminas\laminas-server - 7 * maatwebsite\excel - 7 * magento\zend-db - 6 * pdepend\pdepend - 32 * swiftmailer\swiftmailer - 7 * typo3\cms-extbase - 6 I updated the above gist and Google Sheet links with the data from today. Kind regards, Theodore --- ## #128541 — Gina P. Banyard — 2025-08-24T10:55:08+00:00 URL: https://externals.io/message/128226#128541 · In reply to: #128459 > > > > […] > > Can we propose to undeprecate it before the feature freeze? (Interrupting my holiday slightly to response to this) Yes you can, and this should be the way forward if needed. However, the problems seem to only be with __wakeup()​ rather than __sleep()​ so in any case I don't think a counterproposal should undeprecate the latter. Especially as Tim pointed out on the PR that it is basically impossible to properly implement __sleep()​ if inheritance is involved. [A]​ In any case, going from the analysis from Theodore, and me asking Damien to run an analysis and having a quick skim through them, the main "offenders" are Symfony transient dependencies. Thus, I'm not even sure a proposal to undeprecate it is warranted, as from what I've seen, many implementations as throwing, do validation on the resulting object, or unset() properties. And unless I'm misunderstanding, the concerns raised by Nicolas are things that need to be dealt with by frameworks, and possibly some libraries, rather than end-user code. (And on top of that, it doesn't look like Wordpress would have a hard time at all to support both __unserialize()​ and __wakeup()​.) I don't mind splitting the PR into 2 different ones, one for __sleep()​ and the other one for __wakeup()​, but once again people are complaining that a 2/3 threshold is seemingly not enough when it is not necessarily an easy threshold to pass. Best regards, Gina P. Banyard [A] https://github.com/php/php-src/pull/19435#issuecomment-3180254434 --- ## #128545 — Jakub Zelenka — 2025-08-24T19:14:25+00:00 URL: https://externals.io/message/128226#128545 · In reply to: #128541 Hi, > I don't mind splitting the PR into 2 different ones, one for __sleep() > and the other one for __wakeup(), but once again people are complaining > that a 2/3 threshold is seemingly not enough when it is not necessarily an > easy threshold to pass. > The complaint wasn't that the 2/3 threshold is not enough. It was that the RFC missed some important points and was in that sense misleading. The result was just narrowly passing the threshold. So the point was that it's quite likely it wouldn't pass it if the RFC description was correct. Regards Jakub