Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104524
MIME-Version: 1.0
References: <CAF+90c-GfwWSJ+LUUYrb6gpZRrwP=XX=hWFD9DL-3xQhBOgp+A@mail.gmail.com>
 <CAOWwgp=Wh1JUUYYx7WhDyk_1w5tHF3AX4K46mkpoYS=yWz7ihg@mail.gmail.com>
 <CAF+90c-jiNwT6e3o30B6_x2_waZ79XAYvHN3_8dOc31mU+KvhA@mail.gmail.com> <CAOWwgp=YhKxKHVPoquc451KAi785L+=C6Uiu1NzVbs9LA9m5qA@mail.gmail.com>
In-Reply-To: <CAOWwgp=YhKxKHVPoquc451KAi785L+=C6Uiu1NzVbs9LA9m5qA@mail.gmail.com>
Date: Tue, 26 Feb 2019 15:17:01 +0100
Message-ID: <CAF+90c_Q4_joMi7bC00Ft6zRONS5LH1tM=p6ogJ9EXOjL+5bEQ@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000e1b470582ccb715"
Subject: Re: [RFC] New custom object serialization mechanism
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000000e1b470582ccb715
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 19, 2019 at 11:42 AM Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:

>
>
> Le mar. 19 f=C3=A9vr. 2019 =C3=A0 11:31, Nikita Popov <nikita.ppv@gmail.c=
om> a
> =C3=A9crit :
>
>> On Mon, Feb 18, 2019 at 4:12 PM Nicolas Grekas <
>> nicolas.grekas+php@gmail.com> wrote:
>>
>>> Hi Nikita,
>>>
>>> I'd like to propose a new custom object serialization mechanism intende=
d
>>>> to replace the broken Serializable interface:
>>>>
>>>> https://wiki.php.net/rfc/custom_object_serialization
>>>>
>>>> This was already previously discussed in
>>>> https://externals.io/message/98834, this just brings it into RFC form.
>>>> The latest motivation for this is https://bugs.php.net/bug.php?id=3D77=
302,
>>>> a compatibility issue in 7.3 affecting Symfony, caused by Serializable=
. We
>>>> can't fix Serializable, but we can at least make sure that a working
>>>> alternative exists.
>>>>
>>>
>>> Is there anything we can to do to help the RFC move forward? I'm
>>> spending a great deal of time removing Serializable from the Symfony co=
de
>>> base. It's not pretty nor fun... but we have no choice since as ppl mov=
e to
>>> PHP 7.3, they can now spot when the current mechanism is breaking their
>>> serialized payloads (typically from user objects put in the session
>>> storage).
>>>
>>> About interface vs magic methods, technicaly, we can work with an
>>> interface provided by PHP core, so that if that's a blocker for voters =
to
>>> approve the RFC, let's do it - the current situation is really aweful :=
).
>>> FYI, I found myself implementing some getState()/setState() methods of =
my
>>> own, decoupled from the underlying mechanisms used by PHP. That allows =
me
>>> to still use Serializable for BC reasons when needed, or  move to __sle=
ep
>>> when possible, then move to the new 7.4 style when ready, without requi=
ring
>>> any changes from the consumer POV. That's a good illustration of what I
>>> meant in my previous email: domain-specific interfaces in everyone's co=
de
>>> is a better design as it allows better decoupling. It's also a better
>>> design to express that "instances of this interface of mine MUST be
>>> serializable". IMHO.
>>>
>>> Nicolas
>>>
>>
>> I think for me the main open question here is whether we want to just
>> handle the serialization issue or try to come up with something more
>> general. If we limit this to just serialization, then the design should
>> stay as-is -- for all the reasons you have already outlined, using an
>> interface for this is inappropriate.
>>
>> For a more general mechanism, I think we would need something along the
>> lines of (ignoring naming):
>>
>> interface GetState {
>>     public function getState(string $purpose): array;
>> }
>> interface SetState {
>>     public function setState(array $data, string $purpose): void;
>> }
>>
>> We need separate interfaces for get/set to properly cater to cases like
>> JSON, where only get is meaningful (right now). We need the $purpose
>> argument to allow different state representations for different purposes=
,
>> e.g. JSON will often need more preparation than PHP serialization. The
>> $purpose argument is a string, to allow extension for custom purposes.
>>
>> Seeing that, this is really not something I would feel comfortable with
>> introducing in core PHP. Our track record for introducing reusable
>> general-purpose interfaces is not exactly stellar (say, did you hear abo=
ut
>> SplObserver and SplSubject?) and I wouldn't want to do this without seei=
ng
>> the concept fleshed out extensively in userland first.
>>
>> Nikita
>>
>
> I think the per-purpose representation logic doesn't belong to each
> classes.
> Symfony Serializer does it completly from the outside, and I think that's
> a much better design.
> I'm on the side this should not be in PHP code indeed.
>

As there hasn't been further input here, I'd like to go forward with the
RFC as-is and plan to start voting by Friday.

Nikita

--0000000000000e1b470582ccb715--