[VOTE] Deprecations for PHP 7.4

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

Le 8 juil. 2019 à 21:27, Nikita Popov [email protected] 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

Le 8 juil. 2019 à 21:27, Nikita Popov [email protected] 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