[VOTE] New custom object serialization mechanism

  104538
March 1, 2019 15:08 nikita.ppv@gmail.com (Nikita Popov)
Hi internals,

I have opened voting on https://wiki.php.net/rfc/custom_object_serialization.
The vote will be open until 2019-03-15.

You can find the discussion thread for this proposal here:
https://externals.io/message/103823

Regards,
Nikita
  104585
March 5, 2019 12:18 sebastian@php.net (Sebastian Bergmann)
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.
  104586
March 5, 2019 12:35 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Mar 5, 2019 at 1:18 PM Sebastian Bergmann <sebastian@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
  104604
March 6, 2019 13:41 nicolas.grekas+php@gmail.com (Nicolas Grekas)
> 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. >
I'd feel fine. The plan is aggressive, but Serializable easily produces broken payloads right now, so we need to move away from it as quickly as possible. You didn't mention it, but keeping __sleep/__wakeup as is in 7.4 is fine to me: they do no harm. Deprecating them might be considered in 8.1, but they don't need the same aggressive plan to me. Nicolas
  104607
March 6, 2019 16:21 me@jhdxr.com (=?utf-8?b?Q0hVIFpoYW93ZWk=?=)
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 ppv@gmail.com> 
Sent: Tuesday, March 5, 2019 8:35 PM
To: Sebastian Bergmann <sebastian@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 <sebastian@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