[VOTE] Deprecations for PHP 7.4

  106184
July 8, 2019 19:27 nikita.ppv@gmail.com (Nikita Popov)
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
  106201
July 9, 2019 13:22 claude.pache@gmail.com (Claude Pache)
> Le 8 juil. 2019 à 21:27, Nikita Popov 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
  106202
July 9, 2019 13:38 nikita.ppv@gmail.com (Nikita Popov)
On Tue, Jul 9, 2019 at 3:22 PM Claude Pache pache@gmail.com> wrote:

> > Le 8 juil. 2019 à 21:27, Nikita Popov 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... >
I'm not sure what Kalle meant with that last sentence, but the reason why I personally think restore_include_path() should go away (apart from the obvious uselessness) is that it has a similar name to other restore_* functions, but does not behave in the same way. Functions like restore_error_handler() and restore_exception_handler() operate on a stack and will restore to the last value on that stack. restore_include_path() on the other hand will restore the the original (initial) value. As such, this function doesn't offer anything over ini_restore("include_path") apart from an ambiguous name. get_include_path() and set_include_path() on the other hand do exactly what they say on the tin, and I believe the former at least still sees some practical use. While getting rid of the include_path functionality altogether would certainly be nice, I don't have any particular gripe with these functions. Nikita
  106245
July 22, 2019 09:05 nikita.ppv@gmail.com (Nikita Popov)
On Mon, Jul 8, 2019 at 9:27 PM Nikita Popov ppv@gmail.com> wrote:

> 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 >
Voting has been closed with all proposals accepted. Here are the outcomes for easy reference: (real) cast: 35 to 7, 83% in favor get_magic_quotes_*: 46 to 0, unanimous array_key_exists on objects: 44 to 0, unanimous FILTER_SANITIZE_MAGIC_QUOTES: 45 to 0, unanimous Reflection export() methods: 37 to 4, 90% in favor mb_strrpos() with encoding as 3rd arg: 44 to 0, unanimous implode() with swapped params: 38 to 5, 88% in favor Unbinding $this from non-static closures: 43 to 0, unanimous hebrevc() function: 34 to 7, 83% in favor convert_cyr_string() function: 25 to 7, 78% in favor money_format() function: 34 to 8, 81% in favor ezmlm_hash() function: 37 to 4, 90% in favor restore_include_path() function: 31 to 9, 78% in favor allow_url_include: 43 to 0, unanimous Regards, Nikita