Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77932
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error)
Message-ID: <543C1805.9000700@mabe.berlin>
Date: Mon, 13 Oct 2014 20:20:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
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>
In-Reply-To: <CADyq6sKevr0M0W8d8RRGfsqdtSy5-vqjbRnTq23HRYXTzM1R2g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array()
 and related API
From: php@mabe.berlin (Marc Bennewitz)


On 13.10.2014 02:45, Marco Pivetta 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 in
>> principle they could, eventually, be removed, but I agree with others that
>> it's far too soon to remove a feature which has been around since 4.0 just
>> 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 … syntax.
> 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 that
> I've pasted before, then I'm missing some bits of information that may make
> the entire proposal moot.
Your implementation of "userland_call_user_func" doesn't have the same
visibility as "call_user_func[_array]":
http://3v4l.org/lNgub

>>> 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, then
>> surely an included (and C-level) implementation should be sought which has
>> the better behaviour?
>>
>> This matches my own thoughts. There is nothing wrong with these functions.
>> 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 just
>> 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_*` functions,
> but I assume that I'd only start a giant shitstorm (pardon the wording, but
> that's the most precise term for that) about performance.
>
> Anyway, it's clear that this proposal has short legs, and won't get
> anywhere in a vote.
>
> Greets,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>