Zend: Deprecate __sleep() #19682
Zend: Deprecate __sleep() #19682
Conversation
Girgias
force-pushed
the
8.5-dep-just-sleep
branch
from
adadb0d to
a4e917e
Compare
Girgias
requested review from
bukka,
kamil-tekiela,
SakiTakamachi and
nielsdos
as code owners
Zend/zend_compile.c
Outdated
| @@ -9351,6 +9351,11 @@ static void zend_compile_class_decl(znode *result, zend_ast *ast, bool toplevel) | |||
| ce->ce_flags |= ZEND_ACC_TOP_LEVEL; | |||
| } | |||
|
|
|||
| if (ce->__serialize == NULL && zend_hash_exists(&ce->function_table, ZSTR_KNOWN(ZEND_STR_SLEEP))) { | |||
| zend_error(E_DEPRECATED, "The __sleep() serialization hook has been deprecated." | |||
There was a problem hiding this comment.
Is this called a hook? I thought it was just a magic method. Hook may be confusing wrt property hooks.
Although docs say on one particular page:
Beyond the above advice, note that you can also hook into the serialization and unserialization events on an object using the __sleep() and __wakeup() methods.
There was a problem hiding this comment.
I guess using magic method is less ambiguous. But I did use "hook" because it hooks into the serialization process.
|
Deprecating __sleep and keeping __wakeup seems kind of wierd and not what was voted on. I think this should be re-considered. But will leave it to RM to decide it. |
There was a problem hiding this comment.
Deprecating __sleep and keeping __wakeup seems kind of wierd and not what was voted on. I think this should be re-considered. But will leave it to RM to decide it.
So I'm a little torn. On the one hand, if the plan is still to deprecate __wakeup and it is just the implementation that is being split up, then it would be fine and I would just want to make sure that the implementation is also done in 8.5 since those two methods go together.
If the __wakeup part is not ready yet, then it might be worth delaying the __sleep part so that they are merged together (same PHP version). We have precedent (from yours truly) for implementing deprecations after the version they targeted (8.4 deprecations for output handlers were done in 8.5).
On the other hand, if __wakeup is not planned, then this is clearly something that was not voted on - the vote for deprecation was 18-9, so if even one of those 18 would have objected to deprecating __sleep without also deprecating __wakeup then the proposal would have failed. I can see an argument that keeping __wakeup allows deserialization of objects serialized with the old method, while deprecating __sleep means that there wouldn't be new objects serialized with the old method, but still, I would expect that at least someone would have objected.
So, I guess the question is, are you planning to also deprecate __wakeup in this release?
| if (ce->__serialize == NULL && zend_hash_exists(&ce->function_table, ZSTR_KNOWN(ZEND_STR_SLEEP))) { | ||
| zend_error(E_DEPRECATED, "The __sleep() serialization magic method has been deprecated." | ||
| " Implement __serialize() instead (or in addition, if support for old PHP versions is necessary)"); | ||
| } |
There was a problem hiding this comment.
can you add a test for what happens if the deprecation is turned into an exception?
|
There has not been a counter RFC for "undeprecating" Considering the analysis from @theodorejb (and the results I have from Damien) shows that the main project being impacted is SF and, from what I understand, the problem is with |
RFC: https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_the_sleep_and_wakeup_magic_methods
Split from #19435 as
__sleep()has an extremely easy migration path.