Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103833
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <CAF+90c-v-Y+oj_oVxOu2QRq89TxpqcF3EtOkTdy7DaV89As7Rg@mail.gmail.com>
References: <20190124131514.CD9051000DB@smtp02.mail.de> <CAF+90c8O4DttLY3G=0H8d2fxizDcp61Xud4y2niJRgFPFqPc4g@mail.gmail.com> <CAOWwgpnY=DRRBHiOJX_CEKwxAb1wuTnOCfjy95B4emGbtqfQQw@mail.gmail.com> <96949d28-1b59-4d8b-9db7-6c5047d180f7@www.fastmail.com><CAF+90c-v-Y+oj_oVxOu2QRq89TxpqcF3EtOkTdy7DaV89As7Rg@mail.gmail.com>
To: nikita.ppv@gmail.com
Cc: internals@lists.php.net
Message-ID: <20190124145342.305136480532@dd16914.kasserver.com>
Date: Thu, 24 Jan 2019 15:53:42 +0100 (CET)
Subject: Re: [PHP-DEV] [RFC] New custom object serialization mechanism
From: mails@thomasbley.de ("Thomas Bley")

Nikita Popov wrote on 24.01.2019 15:40:

> On Thu, Jan 24, 2019 at 3:08 PM Larry Garfield <larry@garfieldtech.com>
> wrote:
> 
>> On Thu, Jan 24, 2019, at 8:02 AM, Nicolas Grekas wrote:
>> > Thank you Nikita,
>> >
>> > the RFC looks solid to me. Using magic methods makes perfect sense to
>> allow
>> > a smooth migration path.
>> >
>> > We could enforce that if one of __serialize() or __unserialize() is
>> > > defined, both have to be defined, to avoid running into such cases.
>> >
>> >
>> > That would make sense a lot of sense to me.
>> >
>> >
>> > > Maybe one could use `__normalize()` and `__denormalize()` [...]
>> > >
>> > I'd like that "serialization" appears in some form in the name
>> > >
>> >
>> > An idea: __pre_serialize / __post_unserialize
>> > But __serialize/__unserialize are good to me.
>> >
>> > Nicolas
>>
>> Given that these methods would not be producing/consuming strings but a
>> de-classed representation of the object, I agree that it's closer to
>> "normalize" as Symfony uses the term.  We don't have to use that name
>> specifically but something other than serialize/deserialize seems logical.
>>
>> Also, that in turn suggests that the same mechanism could be leveraged for
>> formats other than the C (or 0?  It's referred to both ways in the RFC)
>> format we all know and grudgingly accept.  Eg, it feels an awful lot like
>> JsonSerializable (which is for serialize only, but also returns an array),
>> and I can definitely see uses for a standard intermediary format that could
>> be encoded to C-serialized, JSON, or XML, or whatever else.  Is there some
>> way that we could allow other systems to hook into it cleanly, such that it
>> becomes a common intermediary format for a variety of stringified formats?
>>
> 
> Thanks for bringing this up. We do have a bit of a proliferation of
> different serialization-related (in the wider sense of the word) methods:
> 
> * __sleep() and __wakeup()
> * Serializable
> * JsonSerializable
> * __set_state()
> 
> It would be nice if we could make this reusable beyond serialization. There
> are two caveats that come to mind:
> 
> * While __serialize() just returns an array, the same as JsonSerializable,
> this does not necessarily mean that they can be combined. PHP's
> serialization mechanism is much more powerful in what is can represent, so
> the return values of __serialize() and JsonSerializable::jsonSerialize()
> might well want to be different. The latter should in particular probably
> not include any non-trivial objects.
> * 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.
> 
> Nikita
> 

Thanks for the rfc and all your contributions!

> * __sleep() and __wakeup()
> * Serializable
> * JsonSerializable
> * __set_state()

To me it's not clear why we need all these methods, for example:

$a = new A();
$aSerialized = serialize($a->toArray());
$aRestored = A::createFromArray(unserialize($aSerialized));

Apart from security problems, problems with versioning and unreadable data in databases,
I don't see many benefits from using serialize()/unserialize().

Regards
Thomas