Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104456
MIME-Version: 1.0
References: <CAF+90c-GfwWSJ+LUUYrb6gpZRrwP=XX=hWFD9DL-3xQhBOgp+A@mail.gmail.com>
In-Reply-To: <CAF+90c-GfwWSJ+LUUYrb6gpZRrwP=XX=hWFD9DL-3xQhBOgp+A@mail.gmail.com>
Date: Mon, 18 Feb 2019 16:12:04 +0100
Message-ID: <CAOWwgp=Wh1JUUYYx7WhDyk_1w5tHF3AX4K46mkpoYS=yWz7ihg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e2347305822c8c23"
Subject: Re: [RFC] New custom object serialization mechanism
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000e2347305822c8c23
Content-Type: text/plain; charset="UTF-8"

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=77302,
> 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 code base. It'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 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 __sleep when possible,
then move to the new 7.4 style when ready, without requiring 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 code 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

--000000000000e2347305822c8c23--