I voted no for similar reason. I understand the problem we have, but I really don't like the idea that just introduce a new method, well actually a pair of new methods, to solve this problem, without any plan to stop userland developer from the wrong use case. The deprecating plan also sounds too rush and aggressive for me. Serialize/unserialize/__sleep/__wakeup are wide used, and deprecating or removing them will be a huge BC break.
PHP 8 is a revolution version IMO, so if a RFC targeting PHP 8 propose to deprecate or removing those 4 methods, I will vote yes. But at the same time, I'd like to ask, is it possible to show warnings only if potential broken detected, e.g. serialize with reference, or parent:: serialize is called. Regards, CHU Zhaowei -----Original Message----- From: Nikita Popov <nikita....@gmail.com> Sent: Tuesday, March 5, 2019 8:35 PM To: Sebastian Bergmann <sebast...@php.net> Cc: PHP internals <internals@lists.php.net> Subject: Re: [PHP-DEV] [VOTE] New custom object serialization mechanism On Tue, Mar 5, 2019 at 1:18 PM Sebastian Bergmann <sebast...@php.net> wrote: > Am 01.03.2019 um 16:08 schrieb Nikita Popov: > > I have opened voting on > https://wiki.php.net/rfc/custom_object_serialization. > > The vote will be open until 2019-03-15. > > I voted "No" because this adds a third mechanism without a concrete > plan to phase out the existing two mechanisms. > Good concern. How do people feel about deprecating Serializable in 7.4 and removing in 8.0 (not as part of this RFC but a separate one)? The deprecation warning would only be thrown if Serializable is implemented but the class has no __serialize/__unserialize. The timeline would be a bit aggressive in that we'd be introducing the replacement in the same release as the deprecation, something I'd usually try to avoid. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
