Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120182
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-386-g2404815117-fm-20230425.001-g24048151
Mime-Version: 1.0
Message-ID: <e3eba528-a015-48be-ba8e-fa71d512aa33@app.fastmail.com>
In-Reply-To: 
 <CAH5C8xXhCkZt7bBs7YcjMBRYM5ggu7W47huCCbVwb2-q_zFnBA@mail.gmail.com>
References: 
 <CAH5C8xXtCVHaxwzmAW_eBxp_D6p7kww9svND=3AEeC9X6--YXg@mail.gmail.com>
 <ffa8138a-f1b6-3926-bc2f-558ffca344b0@gmail.com>
 <CAH5C8xXhCkZt7bBs7YcjMBRYM5ggu7W47huCCbVwb2-q_zFnBA@mail.gmail.com>
Date: Tue, 02 May 2023 16:13:10 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded
 signatures
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, May 2, 2023, at 12:20 PM, M=C3=A1t=C3=A9 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 h=
ere, 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 fr=
om 8.2 to 9.0 is going to be problematic.  Were we earlier in the 8.x cy=
cle it would be less of an issue, but assuming we stick to the usual sch=
edule 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