Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77940
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <543C2A08.9020004@sugarcrm.com>
References: <CADyq6sJxBQ4Mcu9+LRedfFsV-ksdp26eqfWb_XdvP0EsDKS0Bw@mail.gmail.com>
 <543C1E5A.7040405@sugarcrm.com> <CADyq6sKeePkx63yQn5bA0yPdoFgAW+OUHZJRQ6eAT38-iP5miQ@mail.gmail.com>
 <543C2A08.9020004@sugarcrm.com>
Date: Mon, 13 Oct 2014 22:34:25 +0200
Message-ID: <CADyq6sL2xh+S0ruV0zqrzHW8dfsSQMg_2_bjd1mNUS9fitxxew@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7beb95b24e0085050553d475
Subject: Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array()
 and related API
From: ocramius@gmail.com (Marco Pivetta)

--047d7beb95b24e0085050553d475
Content-Type: text/plain; charset=UTF-8

On 13 October 2014 21:37, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> Hi!
>
> > My point is that providing them as "userland implementation" even inside
> > core would be more interesting than having something magic going on
> > under the hood.
>
> It certainly may be "interesting", and nobody prevents you from writing
> a blog or implementing a library doing this. However, it is not the
> reason to change the core functions of PHP.
>

It's not about "changing" them: from a consumer PoV, they'd still be
available.


> > Yes, I realize that complete removal would completely kill PHP's
> > adoption for the next version, so I'm thinking about something like an
> > ini setting:
> >
> > "zeh_legacy_includeh = '/zeh/path/to/old/functions.php';"
>
> You're trying to solve a problem that did not exist before you tried to
> solve it.
>

The problem always existed, and it's that it is very hard to escape from an
API that is dictated by the language itself.
Getting gradually rid of those APIs and making them swappable pieces simply
increases the degree of freedom that we get in our applications, by having
less people rely on stuff like `array_map` and `array_filter` (and the
funny parameter order), because PHP no longer has them under its protective
wing.
My suggestion for `call_user_func` and related deprecation is just spawned
by some debugging raging, but the opportunity to kill a large chunk of the
shipped library stands.

> Yet this would allow removing a lot of internal functions that were
> > written just for the sake of it, and move them to something that can be
> > maintained by a larger userbase.
>
> These functions weren't written "just for the sake of it". They were
> written because people needed it.
>

Right, and now they can be built in a way that isn't coupled with the
engine itself.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--047d7beb95b24e0085050553d475--