Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77930
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.172 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CADyq6sKevr0M0W8d8RRGfsqdtSy5-vqjbRnTq23HRYXTzM1R2g@mail.gmail.com>
References: <CADyq6sJxBQ4Mcu9+LRedfFsV-ksdp26eqfWb_XdvP0EsDKS0Bw@mail.gmail.com>
 <CAPwsocG=mJRuNdzK=AoVOmuddcdZ0tag66fC1CEBWry1zrRndQ@mail.gmail.com>
 <CADyq6sJ6c233LXeL7BQ5eNsQOrcNdR5WwNfO=FfDk-67R0dojw@mail.gmail.com>
 <5439B266.8070300@gmail.com> <AC146B03-731F-41DD-906B-3477E14F3187@ajf.me> <CADyq6sKevr0M0W8d8RRGfsqdtSy5-vqjbRnTq23HRYXTzM1R2g@mail.gmail.com>
Date: Mon, 13 Oct 2014 17:47:39 +0200
Message-ID: <CAMUwpuSiwEsLHwa9Cne4gXhTTVZxuOZoSpP7EWWqJmUM50uZxw@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, Rowan Collins <rowan.collins@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array()
 and related API
From: jpauli@php.net (Julien Pauli)

On Mon, Oct 13, 2014 at 2:45 AM, Marco Pivetta <ocramius@gmail.com> wrote:
> On 12 October 2014 00:47, Andrea Faulds <ajf@ajf.me> wrote:
>
>>
>> On 11 Oct 2014, at 23:42, Rowan Collins <rowan.collins@gmail.com> wrote:
>>
>> > func_get_args() and func_num_args(), OTOH, existed solely to support
>> variadics, and anything taking advantage of them being functions rather
>> than a language structure would have to be quite exotic and arcane, so i=
n
>> principle they could, eventually, be removed, but I agree with others th=
at
>> it's far too soon to remove a feature which has been around since 4.0 ju=
st
>> becuase 5.6 includes a better alternative.
>>
>> They have some (admittedly limited) use beyond variadics. If you make a
>> function and later make it redirect to another, you can preserve your
>> typehints by using func_get_args() rather than using the =E2=80=A6 synta=
x.
>>
>
> Can anyone come up with those use-cases? If there is something that
> `func_get_args()` can do and that can't be done with the code examples th=
at
> I've pasted before, then I'm missing some bits of information that may ma=
ke
> the entire proposal moot.
>
>
>> > If they're included in the core distribution, then why make them
>> optional at all? If it's just a question of how the functions behave, th=
en
>> surely an included (and C-level) implementation should be sought which h=
as
>> the better behaviour?
>>
>> This matches my own thoughts. There is nothing wrong with these function=
s.
>> There are just some issues with their implementation. We do not need to =
get
>> rid of the functions, that would be an absurd overreaction. We should ju=
st
>> fix the implementations.
>
>
> The point is removing more API from core and moving it to userland.
> API implemented in core needs to be maintained by core devs, and is
> non-transparent to consumers (reflection/debugging/etc).
> In general, I've always been against any non-language feature that isn't
> implemented with the language itself, but it's my point of view: as a
> simple rule of thumb (my rule, many would just say I'm crazy), if it can =
be
> implemented in PHP, then don't add it to core or extensions.
> I would suggest the same deprecation approach for many `array_*` function=
s,
> but I assume that I'd only start a giant shitstorm (pardon the wording, b=
ut
> that's the most precise term for that) about performance.

Yep, rewriting array_ functions in PHP will hit a very huge VM
overhead and drop the function's performance dramatically.


For func_get_args() and call_user_func() , we could add a deprecation
notice to PHP7 to tell people there are "better" ways of doing this
now.


Julien.P