Re: [VOTE] Deprecations for PHP 7.4
| From: | Claude Pache | Date: | Tue, 09 Jul 2019 13:22:17 +0000 |
| Subject: | Re: [VOTE] Deprecations for PHP 7.4 | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-106201@lists.php.net to get a copy of this message | ||
> Le 8 juil. 2019 à 21:27, Nikita Popov <nikita.ppv@gmail.com> a écrit :
>
> Hi internals,
>
> I've opened voting on the deprecations for PHP 7.4 RFC:
> https://wiki.php.net/rfc/deprecations_php_7_4
>
> As usual, each deprecation has it's own vote and requires its own,
> independent 2/3 majority to pass. Voting closes July 22nd.
>
> Thanks everyone for their feedback.
>
> Regards,
> Nikita
Hi,
Having actually read the justifications for deprecation of functionality I don’t care about, there
is the following one that I don’t understand:
About restore_include_path(): “This function is essentially an “alias” of doing
ini_restore('include_path'). The main rationale for this is to clean up the standard
library for consistency, similar to what we have done with other functions that are just wrappers
for ini directives.”
But get_include_path() and set_include_path() are not yet deprecated, are they? So much for
consistency...
In fact, I did find the following RFC, that seems to be abandoned: https://wiki.php.net/rfc/deprecate_ini_set_get_aliases
<https://wiki.php.net/rfc/deprecate_ini_set_get_aliases>.
But I haven’t found trace of actual deprecation. Or did I miss something?
—Claude