Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112497
MIME-Version: 1.0
References: <CAF+90c_8Z389ZA2725QDT0bx8sTfaeh4jXRs02E6GZy83pXkVg@mail.gmail.com>
 <283eb44a-d6f9-b91b-115e-cc95e9523c30@telia.com> <CAF+90c_7oO6LpkUrOCOZez210a8E+fbm_S3aVTpDTqm6SXN=Gg@mail.gmail.com>
In-Reply-To: <CAF+90c_7oO6LpkUrOCOZez210a8E+fbm_S3aVTpDTqm6SXN=Gg@mail.gmail.com>
Date: Mon, 14 Dec 2020 18:40:22 +0100
Message-ID: <CAOWwgpnrRRyKiwULJo6mV6ApwLRX1uG4JysRvUrXjVN8Hc618A@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a6369105b670239b"
Subject: Re: [PHP-DEV] Re: [RFC] Phasing out Serializable
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000a6369105b670239b
Content-Type: text/plain; charset="UTF-8"

Hi Nikita,


> > > 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.
>

thank you for the RFC, I fully support it!



> 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().
>

I think it's critical to create a smooth path, and the one you propose is
very sensible to me. We're not in a hurry to remove the interface. It
should just be super clear what the direction is, and this path with a
deprecation works well IMHO.

Nicolas

--000000000000a6369105b670239b--