Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77883
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
Message-ID: <5439B266.8070300@gmail.com>
Date: Sat, 11 Oct 2014 23:42:46 +0100
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>
In-Reply-To: <CADyq6sJ6c233LXeL7BQ5eNsQOrcNdR5WwNfO=FfDk-67R0dojw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array()
 and related API
From: rowan.collins@gmail.com (Rowan Collins)

On 11/10/2014 04:10, Marco Pivetta wrote:

> That would actually be worse, as it wouldn't be possible to pass them to
> methods with a `callable` hint or similars such as `array_map`.

That sounds like a good counter to your own argument that there is no 
use-case for these functions. Indeed, there are plenty of use cases for 
call_user_func() and call_user_func_array() which have nothing 
whatsoever to do with variadics, so are as valid as they ever were.

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.

> In general, I understand why there's a lot of fuss about BC compat here,
> but I don't see why providing them as separate file or using something like
> a "global include" is a problem. Is/would something like that (be) possible
> via ini setting?

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?

Regards,

-- 
Rowan Collins
[IMSoP]