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
