Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112458
MIME-Version: 1.0
References: <CAF+90c_8Z389ZA2725QDT0bx8sTfaeh4jXRs02E6GZy83pXkVg@mail.gmail.com>
 <283eb44a-d6f9-b91b-115e-cc95e9523c30@telia.com>
In-Reply-To: <283eb44a-d6f9-b91b-115e-cc95e9523c30@telia.com>
Date: Mon, 7 Dec 2020 16:49:53 +0100
Message-ID: <CAF+90c_7oO6LpkUrOCOZez210a8E+fbm_S3aVTpDTqm6SXN=Gg@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e8e97305b5e1c796"
Subject: Re: [RFC] Phasing out Serializable
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000e8e97305b5e1c796
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Dec 7, 2020 at 3:49 PM Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.co=
m>
wrote:

> Den 2020-12-07 kl. 15:11, skrev Nikita Popov:
>
> > Hi internals,
> >
> > Picking up a loose thread:
> > https://wiki.php.net/rfc/custom_object_serialization introduced a
> > replacement for Serializable in PHP 7.4, so it's time to think about
> > deprecating and removing the old mechanism:
> >
> > https://wiki.php.net/rfc/phase_out_serializable
> >
> > This RFC follows a rather conversative approach. In PHP 8.1 there will
> be a
> > deprecation warning if Serializable is implemented without also
> > implementing __serialize() and __unserialize(). In PHP 9.0, support for
> > Serializable is dropped internally, and only the interface retained. In
> PHP
> > 10.0 the interface is dropped as well.
> >
> > Regards,
> > Nikita
>

I had to slightly extend this RFC to also deprecate & remove the
PDO::FETCH_SERIALIZE mode, which is based on Serializable. Doesn't seem to
be a big loss, as this fetch mode isn't working correctly in the first
place...


> Given that 10.0 lies maybe ten years in the future if we have a similar
> timeline
> like for 7.0 to 8.0. Is it then realistic to have such a long-term
> planning? For me
> it feels a bit more prudent to remove it completely in 9.0.
>
> Otherwise +1!
>

I'd be also okay with dropping it entirely in PHP 9. That would mean that
there is no prior deprecation warning if you implement it together with
__serialize() and __unserialize() though, which is why I went with the
proposed timeline. From my own (technical) perspective, the case is closed
in PHP 9 either way, because that's where we can rip out support in
unserialize().

Nikita

--000000000000e8e97305b5e1c796--