Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77906
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <AC146B03-731F-41DD-906B-3477E14F3187@ajf.me>
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>
Date: Mon, 13 Oct 2014 02:45:22 +0200
Message-ID: <CADyq6sKevr0M0W8d8RRGfsqdtSy5-vqjbRnTq23HRYXTzM1R2g@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1133cdb0eecb680505433770
Subject: Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array()
 and related API
From: ocramius@gmail.com (Marco Pivetta)

--001a1133cdb0eecb680505433770
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 tha=
t
> it's far too soon to remove a feature which has been around since 4.0 jus=
t
> 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 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.


> > 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, the=
n
> surely an included (and C-level) implementation should be sought which ha=
s
> 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 g=
et
> rid of the functions, that would be an absurd overreaction. We should jus=
t
> 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/

--001a1133cdb0eecb680505433770--