Den 2020-12-07 kl. 16:49, skrev Nikita Popov:
On Mon, Dec 7, 2020 at 3:49 PM Björn Larsson <bjorn.x.lars...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
