Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112784
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>
 <6fed4bf0-fa17-c5b5-509f-631e561af037@telia.com>
In-Reply-To: <6fed4bf0-fa17-c5b5-509f-631e561af037@telia.com>
Date: Wed, 6 Jan 2021 17:51:24 +0100
Message-ID: <CAF+90c8UvvezuGu+K-21qAjWAfQNCqroaJvBv9vJvdq8LJVh2w@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="0000000000001c2f8f05b83e2311"
Subject: Re: [PHP-DEV] Re: [RFC] Phasing out Serializable
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000001c2f8f05b83e2311
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 15, 2020 at 12:14 AM Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.=
com>
wrote:

> Den 2020-12-07 kl. 16:49, skrev Nikita Popov:
> > On Mon, Dec 7, 2020 at 3:49 PM Bj=C3=B6rn Larsson <bjorn.x.larsson@teli=
a.com>
> > 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 wil=
l
> >> be a
> >>> deprecation warning if Serializable is implemented without also
> >>> implementing __serialize() and __unserialize(). In PHP 9.0, support f=
or
> >>> 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 simila=
r
> >> 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 th=
at
> > 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
> >
> Not sure I understand why no deprecation warning is needed in 8.1,
> if removing completely in 9.0?
>

The current proposed timeline only removes in PHP 9.0 what was deprecated
in PHP 8.1. Possibly I'm misunderstanding what you have in mind here.

Anyway, my main objection towards the proposed timeline is not so
> much about the functionality removed. It's more related with that
> I think an RFC that mandates what should happen in 10.0, maybe
> 10 years into the future feels a bit farfetched.
>
> Of course there could be exceptions for RFC's targeting PHP 10.0,
> but then I think it should be for something big, like replacing
> the SPL library etc.
>

I'm not sure I understand what your actual concern here is. Yes, it's a
long-term plan, but why is that a problem? Why should long-term planning
only be limited to major changes? Even a simple deprecation already works
on a 5 year timeline, between deprecation and removal. Of course, I have no
idea whether I'll still be involved with the PHP project in ten years time,
but I suspect there will always be someone who enjoys deleting deprecated
code to carry out the will ;)

Regards,
Nikita

--0000000000001c2f8f05b83e2311--