Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77856
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4D642F36-81F2-42DD-876D-78B4B8368214@ajf.me>
References: <CADyq6sJxBQ4Mcu9+LRedfFsV-ksdp26eqfWb_XdvP0EsDKS0Bw@mail.gmail.com>
	<4D642F36-81F2-42DD-876D-78B4B8368214@ajf.me>
Date: Fri, 10 Oct 2014 13:39:55 -0700
Message-ID: <CAKOpQSwgmG4-cz+1DjzcL9XS1hk-AbrcJiLYp6bfshhU-bNs=A@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Marco Pivetta <ocramius@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3319e3742d80505178d4f
Subject: Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array()
 and related API
From: kris.craig@gmail.com (Kris Craig)

--001a11c3319e3742d80505178d4f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 10, 2014 at 1:34 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
> On 10 Oct 2014, at 21:27, Marco Pivetta <ocramius@gmail.com> wrote:
>
> > While rambling with some code today, I realized that `call_user_func`
> > behaves strangely, appearing and disappearing from stack traces dependi=
ng
> > on versions of PHP. For an example, compare
> > http://3v4l.org/fGpIk#vphp7@20140901, http://3v4l.org/fGpIk#v530 and
> > http://3v4l.org/fGpIk#vhhvm-301.
>
> IIRC this is a bug caused by PHP7 eliminating the call to the function
> entirely, and instead inserting a normal function call opcode. See:
> https://github.com/php/php-src/blob/292421d3a1fcefe88c3017ffdb9f889c39a6c=
8c1/Zend/zend_compile.c#L2777
>
> This could possibly be fixed somehow.
>
> > Additionally, it seems like `call_user_func` and similars are impacting
> > performance in some parts of my codebase (event dispatcher logic).
>
> In PHP 7, due to the function call removal, it should be just the same,
> performance-wise, as a normal function call.
>
> > Therefore, here comes my idea of simply getting rid of `call_user_func`=
,
> > `call_user_func_array`, `func_get_args`, `func_num_args` and
> `func_get_arg`.
> >
> > My plan for it would be to add a deprecation (notice? not sure about
> that)
> > in PHP 5.7, and a complete removal of those methods in PHP 7.0.
> >
> > BC compatibility is easily achieved as variadics (
> > https://wiki.php.net/rfc/variadics) allow for writing cleaner and less
> > complex versions:
>
> =E2=80=9CEasily=E2=80=9D achieved? No. This would break an awful, awful l=
ot of existing
> PHP code with no gain. There=E2=80=99s no need to deprecate it any time s=
oon. The
> variadics syntax is merely a nicer alternative. We should not force peopl=
e
> to rewrite existing code to use it. There is absolutely no need to get ri=
d
> of func_get_args.
>
> I would vote against any such proposal, and I hope others on the list
> would join me in doing so.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Agreed.  The call_user_func() and call_user_func_array() functions are used
all over the place.  I see absolutely no gain, whatsoever in removing them
and forcing developers to write their own userland variants instead.

--Kris

--001a11c3319e3742d80505178d4f--