Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:103830
MIME-Version: 1.0
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>
In-Reply-To: <96949d28-1b59-4d8b-9db7-6c5047d180f7@www.fastmail.com>
Date: Thu, 24 Jan 2019 15:40:15 +0100
Message-ID: <CAF+90c-v-Y+oj_oVxOu2QRq89TxpqcF3EtOkTdy7DaV89As7Rg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000420dae05803531c9"
Subject: Re: [PHP-DEV] [RFC] New custom object serialization mechanism
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000420dae05803531c9
Content-Type: text/plain; charset="UTF-8"

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

--000000000000420dae05803531c9--