Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106202
MIME-Version: 1.0
References: <CAF+90c_gx-HcMaVHB+3WZNT6SvWSZJxWAhNqO5wf_eOX9UD0eQ@mail.gmail.com>
 <676EE5E8-3C1D-41B7-8B7B-C7F24E673F95@gmail.com>
In-Reply-To: <676EE5E8-3C1D-41B7-8B7B-C7F24E673F95@gmail.com>
Date: Tue, 9 Jul 2019 15:38:42 +0200
Message-ID: <CAF+90c-DroNgvjQ1faZpfio_R6UVMfvVC=BsOJfrmdL7hzZdAg@mail.gmail.com>
To: Claude Pache <claude.pache@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c39c06058d3fae6a"
Subject: Re: [PHP-DEV] [VOTE] Deprecations for PHP 7.4
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000c39c06058d3fae6a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 9, 2019 at 3:22 PM Claude Pache <claude.pache@gmail.com> wrote:

>
> Le 8 juil. 2019 =C3=A0 21:27, Nikita Popov <nikita.ppv@gmail.com> a =C3=
=A9crit :
>
> 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=E2=80=99t care about, there is the following one that I don=E2=80=99t=
 understand:
>
> About restore_include_path(): =E2=80=9CThis function is essentially an =
=E2=80=9Calias=E2=80=9D of
> doing ini_restore('include_path'). The main rationale for this is to clea=
n
> up the standard library for consistency, similar to what we have done wit=
h
> other functions that are just wrappers for ini directives.=E2=80=9D
>
> 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

--000000000000c39c06058d3fae6a--