Le 8 juil. 2019 à 21:27, Nikita Popov [email protected] a écrit :
I've opened voting on the deprecations for PHP 7.4 RFC:
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.
Having actually read the justifications for deprecation of functionality I
don’t care about, there is the following one that I don’t understand:
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.”
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
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_exception_handler() operate on a stack
and will restore to the last value on that stack.
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.
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