On Tue, May 2, 2023, at 12:20 PM, Máté Kocsis wrote: > As far as I see there are more deprecations which are easy to fix. In order > to see the whole picture > better, let's group the functions based on how a possible upgrade path > would look like: > > - With existing suggested alternative: > - get_class() and get_parent_class() > - pg_fetch_result(), pg_field_prtlen(), and pg_field_is_null() > - Phar::setStub() > - ReflectionMethod::__construct() > - ReflectionProperty::setValue() > - session_set_save_handler() (because the OO and procedural style are > interchangeable) > - stream_context_set_option() > - Polyfillable: > - assert_options() > - ldap_connect() > - ldap_exop() > - Requires conditional version check: > - DatePeriod::__construct() > - IntlCalendar::set() > - IntlGregorianCalendar::__construct() > > (I intentionally did not include the FFI related methods, since this > section is TBD) > > As it can be seen, most deprecations have an existing alternative. The 2nd > category (polyfillable ones) > mostly contains very little used functions, especially because the > deprecation of ldap_connect() only > affects PHP compiled with OracleLDAP.
Thanks for the breakdown. I am also generally in favor of the changes here, but am concerned about the migration path. The key factor, IMO, is that it should be possible to run code without version checks across as wide a range of versions as feasible. Needing version checks to run from 8.2 to 9.0 is going to be problematic. Were we earlier in the 8.x cycle it would be less of an issue, but assuming we stick to the usual schedule it feels too tight on those. As Rowan asked, how much would it hurt to leave the date-related methods available but deprecated until 10.x? I'm also not entirely clear how you'd polyfill functions that exist, but change behavior. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
