[RFC] Phasing out Serializable View as Markdown

Den 2021-01-08 kl. 00:23, skrev Björn Larsson:

Den 2021-01-06 kl. 17:51, skrev Nikita Popov:

On Tue, Dec 15, 2020 at 12:14 AM Björn Larsson
<bjorn.x.larsson@telia.com mailto: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örn Larsson
<bjorn.x.larsson@telia.com <mailto: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
<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
<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?

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.

Ok, then I read it wrong, completely fine with above.

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 ;)

Not sure we had RFC's earlier with a ten year lifespan. So I have
a concern about how realistic it would be ;-) The RFC is targetting
two major versions, think it would be cleaner to target only one
of them, not two.

Now we have this RFC for 8.1 and we remove it it in the first step in
9.0 followed by removing it completely in 10.0. One motive for this
as I understand it, is the <7.4 support.

Anyway, come to think on the RFC "Remove PHP 4 Constructors"
which targeted 7.0 and then it was removed completely in 8.0.
Also thinking on the 7.4 deprecation RFC, where the items was
removed in 8.0.

So is it by having this RFC targeting 8.1, we get five extra years
or is it the <7.4 support?

r//Björn L

After thinking a bit more my objection is twofold. One is the long
timeline, targetting 10.0 and at least for me it's not clear why not
having 9.0 as the endpoint is good enough.

Secondly, we introduce a three step approach, targetting both 8.1, 9.0
and 10.0. Is this something that also could come into play for other
deprecations and what is then the criteria for it?

Like the planned 8.1 deprecations:

• https://wiki.php.net/rfc/deprecations_php_8_0

r//Björn L