Kamil Tekiela wrote: > > I think one year of deprecation is not enough... It doesn't make > > sense to me to add a replacement but not deprecate the old variant.
Máté Kocsis <kocsismat...@gmail.com> wrote: > Yes, this upgrade path also makes sense to me, and I'm happy to go with > it if others don't disagree! For the functions that are having new separate methods added, not deprecating them immediately makes upgrading easier. When upgrading from one version of PHP to the next, it is best if you can run the same code on both versions, without any deprecation notices going off. Would leaving the current versions in place and working actually cause any maintenance issues? If not, then we could just move really slowly on deprecating them. We could deprecate them at some point in the 9.x release cycle and remove them in 10.0. The RFC says: > Impact analysis: 1 out of the 2000 most popular PHP packages rely on calling > session_set_save_handler() with 6 or more arguments. I doubt analysing github is going to give a useful measure of the impact of this RFC. Functions like session_set_save_handler are going to be used in custom code written for a company than in shared libraries. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
