[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
  104854
March 21, 2019 14:20 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Mar 1, 2019 at 4:08 PM Nikita Popov ppv@gmail.com> wrote:

> 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 >
Vote closed a bit late here ... the RFC is accepted with 20 votes in favor and 7 against. Regarding deprecation, I think I will target this at PHP 8. The new mechanism will be there for the people who are running into the limits of the existing one, but we probably don't need everybody to switch over right this minute just yet. Regards, Nikita
  105132
April 7, 2019 12:55 benjamin.morel@gmail.com (Benjamin Morel)
Thanks for bringing this new serialization method to PHP 7.4, Nikita!

It would be nice if we could make this reusable beyond serialization. There
> are two caveats that come to mind: > (...) > The __unserialize() method assumes an already constructed object on > which __unserialize() can be called, which we need due to the peculiar > limitations of serialization in PHP, but which is probably not very > convenient for other purposes, where the approach of __set_state() is more > useful.
I actually started working on a replacement for var_export(), that makes use of __serialize() and __unserialize() methods when available, to reconstruct an object: https://github.com/brick/varexporter It turns out that it works pretty well, here is an example output for an object that implements these methods: (static function() { $class = new \ReflectionClass(\My\CustomClass::class); $object = $class->newInstanceWithoutConstructor(); $object->__unserialize([ 'foo' => 'Test', 'bar' => 1234 ]); return $object; })() And the good thing is, it can use these methods right now, without waiting for PHP 7.4. Feedback welcome! Ben On Thu, 21 Mar 2019 at 15:20, Nikita Popov ppv@gmail.com> wrote:
> On Fri, Mar 1, 2019 at 4:08 PM Nikita Popov ppv@gmail.com> wrote: > > > 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 > > > > Vote closed a bit late here ... the RFC is accepted with 20 votes in favor > and 7 against. > > Regarding deprecation, I think I will target this at PHP 8. The new > mechanism will be there for the people who are running into the limits of > the existing one, but we probably don't need everybody to switch over right > this minute just yet. > > Regards, > Nikita >