On Tue, Jul 9, 2019 at 3:22 PM Claude Pache <claude.pa...@gmail.com> wrote:
> > Le 8 juil. 2019 à 21:27, Nikita Popov <nikita....@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
