Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104473
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>
In-Reply-To: <CAF+90c-jiNwT6e3o30B6_x2_waZ79XAYvHN3_8dOc31mU+KvhA@mail.gmail.com>
Date: Tue, 19 Feb 2019 11:42:38 +0100
Message-ID: <CAOWwgp=YhKxKHVPoquc451KAi785L+=C6Uiu1NzVbs9LA9m5qA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001877d405823ce768"
Subject: Re: [RFC] New custom object serialization mechanism
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--0000000000001877d405823ce768
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le mar. 19 f=C3=A9vr. 2019 =C3=A0 11:31, Nikita Popov <nikita.ppv@gmail.com=
> 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 intended
>>> 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=3D773=
02,
>>> 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 spendin=
g
>> a great deal of time removing Serializable from the Symfony code base. I=
t's
>> not pretty nor fun... but we have no choice since as ppl move to PHP 7.3=
,
>> they can now spot when the current mechanism is breaking their serialize=
d
>> 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 t=
o
>> approve the RFC, let's do it - the current situation is really aweful :)=
.
>> FYI, I found myself implementing some getState()/setState() methods of m=
y
>> own, decoupled from the underlying mechanisms used by PHP. That allows m=
e
>> to still use Serializable for BC reasons when needed, or  move to __slee=
p
>> when possible, then move to the new 7.4 style when ready, without requir=
ing
>> 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 cod=
e
>> 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 abou=
t
> SplObserver and SplSubject?) and I wouldn't want to do this without seein=
g
> 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.

Nicolas

--0000000000001877d405823ce768--