Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112509
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <CAF+90c_8Z389ZA2725QDT0bx8sTfaeh4jXRs02E6GZy83pXkVg@mail.gmail.com>
 <283eb44a-d6f9-b91b-115e-cc95e9523c30@telia.com>
 <CAF+90c_7oO6LpkUrOCOZez210a8E+fbm_S3aVTpDTqm6SXN=Gg@mail.gmail.com>
Message-ID: <6fed4bf0-fa17-c5b5-509f-631e561af037@telia.com>
Date: Tue, 15 Dec 2020 00:13:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c_7oO6LpkUrOCOZez210a8E+fbm_S3aVTpDTqm6SXN=Gg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Subject: Re: [RFC] Phasing out Serializable
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2020-12-07 kl. 16:49, skrev Nikita Popov:
> On Mon, Dec 7, 2020 at 3:49 PM Björn Larsson <bjorn.x.larsson@telia.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 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
> 
Not sure I understand why no deprecation warning is needed in 8.1,
if removing completely in 9.0?

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.

r//Björn L