# Deprecation of func_get_args(), call_user_func_array() and related API

- Thread: https://externals.io/message/77854
- Original archive: https://news-web.php.net/php.internals/77854
- Started by Marco Pivetta on 2014-10-10T20:27:59+00:00
- Messages: 29
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/77854.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #77854 — Marco Pivetta — 2014-10-10T20:27:59+00:00

URL: https://externals.io/message/77854#77854

Hello folks,

While rambling with some code today, I realized that `call_user_func`
behaves strangely, appearing and disappearing from stack traces depending
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.

This makes debugging code quite complicated if not just annoying and
frustrating.
Additionally, it seems like `call_user_func` and similars are impacting
performance in some parts of my codebase (event dispatcher logic).

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:

 - http://3v4l.org/HDQb6 (call_user_func)
 - http://3v4l.org/AgEG5 (call_user_func_array)
 - http://3v4l.org/O3G6T (func_get_args) (broken in HHVM)
 - http://3v4l.org/vcYso (func_get_arg) (broken in HHVM)
 - http://3v4l.org/cg8i0 (func_num_args) (broken in HHVM)

Those files could moved to a library and included when running on legacy
codebases. Eventually, grepping for those function calls is also trivial.

Here's also the example with the exception and the userland implementation
of `call_user_func`, which has a much more readable/clear/inspectable stack
trace: http://3v4l.org/i4G8c

Thoughts? If this idea gets enough traction, I'd gladly go and ask for
karma, open an RFC and eventually provide a patch if I'm able to.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #77855 — Andrea Faulds — 2014-10-10T20:34:37+00:00

URL: https://externals.io/message/77854#77855 · In reply to: #77854

> While rambling with some code today, I realized that `call_user_func`
> behaves strangely, appearing and disappearing from stack traces depending
> 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/292421d3a1fcefe88c3017ffdb9f889c39a6c8c1/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:

“Easily” achieved? No. This would break an awful, awful lot of existing PHP code with no gain. There’s no need to deprecate it any time soon. The variadics syntax is merely a nicer alternative. We should not force people to rewrite existing code to use it. There is absolutely no need to get rid 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/

---

## #77856 — Kris Craig — 2014-10-10T20:39:55+00:00

URL: https://externals.io/message/77854#77856 · In reply to: #77855

>
> 
>
> > […]
>
> 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/292421d3a1fcefe88c3017ffdb9f889c39a6c8c1/Zend/zend_compile.c#L2777
>
> This could possibly be fixed somehow.
>
> > […]
>
> In PHP 7, due to the function call removal, it should be just the same,
> performance-wise, as a normal function call.
>
> > […]
> `func_get_arg`.
> > […]
> that)
> > […]
>
> “Easily” achieved? No. This would break an awful, awful lot of existing
> PHP code with no gain. There’s no need to deprecate it any time soon. The
> variadics syntax is merely a nicer alternative. We should not force people
> to rewrite existing code to use it. There is absolutely no need to get rid
> 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/
>
>
>
>
>
> --
> 
> 
>
>
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

---

## #77857 — Marco Pivetta — 2014-10-10T20:40:39+00:00

URL: https://externals.io/message/77854#77857 · In reply to: #77855

>
> 
>
> > […]
>
> 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/292421d3a1fcefe88c3017ffdb9f889c39a6c8c1/Zend/zend_compile.c#L2777
>
> This could possibly be fixed somehow.
>

Having the stack trace entry there would be enough too.


> > […]
>
> In PHP 7, due to the function call removal, it should be just the same,
> performance-wise, as a normal function call.
>

Good to know! And I suppose no additional stack frame is created either?


> > […]
> `func_get_arg`.
> > […]
> that)
> > […]
>
> “Easily” achieved? No. This would break an awful, awful lot of existing
> PHP code with no gain. There’s no need to deprecate it any time soon. The
> variadics syntax is merely a nicer alternative. We should not force people
> to rewrite existing code to use it. There is absolutely no need to get rid
> of func_get_args.
>
> I would vote against any such proposal, and I hope others on the list
> would join me in doing so.
>

I'd actually just deprecate any API for which there isn't a use-case
anymore, but that's my own vision.
As I've already demonstrated, a polyfill already exists and is easy to
implement/use too. Exactly like what happened with `register_globals`
(which is much harder to find), it would be a small addition at the
beginning of <whatever-legacy-thing> you are using.

Could you elaborate a bit on this?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #77859 — Marco Pivetta — 2014-10-10T20:43:05+00:00

URL: https://externals.io/message/77854#77859 · In reply to: #77856

> 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
>
>
Of course they are, but that's obviously because any codebase written so
far didn't have PHP 5.6 support :-)
The main point here is moving forward and killing API that has no use-case
anymore (and has to be maintained).

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #77860 — Andrea Faulds — 2014-10-10T20:46:36+00:00

URL: https://externals.io/message/77854#77860 · In reply to: #77859

> 
> 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
> 
> 
> Of course they are, but that's obviously because any codebase written so far didn't have PHP 5.6 support :-)
> The main point here is moving forward and killing API that has no use-case anymore (and has to be maintained).

PHP 5.6 has been out for *less than two months*. Let’s say PHP 7 comes out in 18 months’ time, so June 2016. Even then, PHP 5.6 would have been around for less than 20 months. It is incredibly unreasonable to suggest that application developers should move to this new API and completely suspend usage of the previous one in such a short timespan (especially given how few people will have moved to 5.6 by then) for a non-security fix.

--
Andrea Faulds
http://ajf.me/

---

## #77861 — Marco Pivetta — 2014-10-10T20:53:18+00:00

URL: https://externals.io/message/77854#77861 · In reply to: #77860

> PHP 5.6 has been out for *less than two months*. Let’s say PHP 7 comes out
> in 18 months’ time, so June 2016. Even then, PHP 5.6 would have been around
> for less than 20 months. It is incredibly unreasonable to suggest that
> application developers should move to this new API and completely suspend
> usage of the previous one in such a short timespan (especially given how
> few people will have moved to 5.6 by then) for a non-security fix.
>

Assuming PHP 7.0 came out in 2 years from now, I don't expect a decent
adoption rate anyway for the next 5 years.
Even in such a case, isn't it possible to have PHP "include" the polyfill
from an actual location instead of basing the function definition on some
internals voodoo?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #77865 — johannes@schlueters.de — 2014-10-10T23:23:16+00:00

URL: https://externals.io/message/77854#77865 · In reply to: #77861

> Assuming PHP 7.0 came out in 2 years from now, I don't expect a decent
> adoption rate anyway for the next 5 years.

So you want to decrease adoption rate even more for a very small win?
Fantastic (irony!)

johannes

---

## #77866 — Leigh — 2014-10-10T23:24:32+00:00

URL: https://externals.io/message/77854#77866 · In reply to: #77854

> Hello folks,
>
> While rambling with some code today, I realized that `call_user_func`
> behaves strangely, appearing and disappearing from stack traces depending
> 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.
>

Ok. Knee jerk reaction is +1 for consistency, we should decide on what
is the expected and accepted behaviour and make sure tests are written
so that we don't deviate from that.

> 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.
>

I understand your impulse, but I agree with others, these are far too
widely used to be deprecated like this

> BC compatibility is easily achieved as variadics (
> https://wiki.php.net/rfc/variadics) allow for writing cleaner and less
> complex versions:
>

True.

So can we make these functions behave as if variadics were used
without removing them? Something akin to making these functions
language constructs?

---

## #77872 — Marco Pivetta — 2014-10-11T03:10:42+00:00

URL: https://externals.io/message/77854#77872 · In reply to: #77866

> > […]
>
> True.
>
> So can we make these functions behave as if variadics were used
> without removing them? Something akin to making these functions
> language constructs?
>

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`.

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?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #77878 — Pierre Joye — 2014-10-11T13:39:23+00:00

URL: https://externals.io/message/77854#77878 · In reply to: #77855

>

> I would vote against any such proposal, and I hope others on the list
would join me in doing so.

I fully agree with you here.

---

## #77883 — Rowan Collins — 2014-10-11T22:42:46+00:00

URL: https://externals.io/message/77854#77883 · In reply to: #77872

> 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]

---

## #77884 — Andrea Faulds — 2014-10-11T22:47:31+00:00

URL: https://externals.io/message/77854#77884 · In reply to: #77883

> `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.

> 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.
--
Andrea Faulds
http://ajf.me/

---

## #77906 — Marco Pivetta — 2014-10-13T00:45:22+00:00

URL: https://externals.io/message/77854#77906 · In reply to: #77884

>
> 
>
> > […]
> 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.


> > […]
> 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/

---

## #77907 — johannes@schlueters.de — 2014-10-13T02:00:10+00:00

URL: https://externals.io/message/77854#77907 · In reply to: #77906

> 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.

For *adding* features that is a good rule. For removing not. Even less
for a feature with more than a million hits on GitHub ...
https://github.com/search?l=php&q=func_get_args&type=Code&utf8=%E2%9C%93
(while that metric is bad - too many duplicates due to forks and from
phpt test suite, but still a notable number)

johannes

---

## #77930 — Julien Pauli — 2014-10-13T15:47:39+00:00

URL: https://externals.io/message/77854#77930 · In reply to: #77906

> 
>
> > […]
>
> 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.
>
>
> > […]
>
>
> 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.

Yep, rewriting array_ functions in PHP will hit a very huge VM
overhead and drop the function's performance dramatically.


For `func_get_args()` and `call_user_func()` , we could add a deprecation
notice to PHP7 to tell people there are "better" ways of doing this
now.


Julien.P

---

## #77932 — Marc Bennewitz — 2014-10-13T18:20:53+00:00

URL: https://externals.io/message/77854#77932 · In reply to: #77906

> 
>
> > […]
> 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

> > […]
>
> 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/

---

## #77933 — Stas Malyshev — 2014-10-13T18:47:54+00:00

URL: https://externals.io/message/77854#77933 · In reply to: #77854

Hi!

> While rambling with some code today, I realized that `call_user_func`
> behaves strangely, appearing and disappearing from stack traces depending
> on versions of PHP. 

If there's a problem with these functions, some bug in backtrace
reporting, they of course need to be fixed. However I see no reason at
all to deprecate a widely used function and create a myriad of BC issues
for no gain at all. Compatibility is a feature, and not only it is just
a feature - it's one of the most requested and most influential
features. BC breaks delay adoption of new versions by years, even for
minor things. For major widely used things

Please, when proposing removing something from PHP, check:
1. If it is widely used
2. If its removal gains huge benefit for PHP which can not be achieved
by any other way

If you answer yes on 1 or no on 2, then there's no point proposing this
removal. That would only make the next version unadoptable for a decade.
Remember, we still have people reluctant to move to 5.4, and you propose
to have them to rewrite all their code and wait until all their
libraries are rewritten (major cause of python 3 adoption problems is
libraries) for what exactly?

Yes, we can rewrite these functions in userland. So we can may others.
The long standing tradition of PHP in this area is to go the extra mile
for the user and actually provide helpful functions, even when
duplicating the functionality already available in user-land, for the
convenience of the user. But this is for adding things. For removing
things, bar is much, much higher.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

---

## #77934 — Marco Pivetta — 2014-10-13T18:48:36+00:00

URL: https://externals.io/message/77854#77934 · In reply to: #77932

>
> 
>
> Your implementation of "userland_call_user_func" doesn't have the same
> visibility as "call_user_func[_array]":
> http://3v4l.org/lNgub


Interesting: this seems to show that it's even more magic than I expected.

Here's just a hacked-together example, just to show that it can be done in
userland as well (there may be better ways): http://3v4l.org/QuQM1#v560

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #77935 — Marco Pivetta — 2014-10-13T18:55:25+00:00

URL: https://externals.io/message/77854#77935 · In reply to: #77933

> Yes, we can rewrite these functions in userland. So we can may others.
> The long standing tradition of PHP in this area is to go the extra mile
> for the user and actually provide helpful functions


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.
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';"

Stupid idea?
Security implications?
And of course "yet another ini setting".

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.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #77936 — Marc Bennewitz — 2014-10-13T19:18:21+00:00

URL: https://externals.io/message/77854#77936 · In reply to: #77934

> On 13 October 2014 20:20, Marc Bennewitz <php@mabe.berlin
> <mailto:php@mabe.berlin>> wrote:
>
>
>     
>
>     Your implementation of "userland_call_user_func" doesn't have the same
>     visibility as "call_user_func[_array]":
>     http://3v4l.org/lNgub
>
>
> Interesting: this seems to show that it's even more magic than I expected.
>
> Here's just a hacked-together example, just to show that it can be
> done in userland as well (there may be better ways):
> http://3v4l.org/QuQM1#v560
Now you have the opposite issue - you are able to call private/protected
methods but you shouldn't:
http://3v4l.org/rgmh8#v560

>
> Marco Pivetta
>
> http://twitter.com/Ocramius     
>
> http://ocramius.github.com/

---

## #77937 — Stas Malyshev — 2014-10-13T19:37:44+00:00

URL: https://externals.io/message/77854#77937 · In reply to: #77935

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.

> 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.

> 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.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

---

## #77939 — Marco Pivetta — 2014-10-13T20:26:22+00:00

URL: https://externals.io/message/77854#77939 · In reply to: #77936

>
> 
>
>  
>
> > […]
>
>
>  Interesting: this seems to show that it's even more magic than I
> expected.
>
>  Here's just a hacked-together example, just to show that it can be done
> in userland as well (there may be better ways): http://3v4l.org/QuQM1#v560
>
> Now you have the opposite issue - you are able to call private/protected
> methods but you shouldn't:
> http://3v4l.org/rgmh8#v560
>
>
Good catch, but I'm not trying to build a complete solution in a gist: if I
do, then I'll just make a lib and include all existing `.phpt` tests
related to `call_user_func`, no? :-)
Just a revision of the userland version, for fun: http://3v4l.org/6IKKl#v560

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

---

## #77940 — Marco Pivetta — 2014-10-13T20:34:25+00:00

URL: https://externals.io/message/77854#77940 · In reply to: #77937

> Hi!
>
> > […]
>
> 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.


> > […]
>
> 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
> > […]
>
> 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/

---

## #77941 — Stas Malyshev — 2014-10-13T20:40:01+00:00

URL: https://externals.io/message/77854#77941 · In reply to: #77940

Hi!

> The problem always existed, and it's that it is very hard to escape from
> an API that is dictated by the language itself.

It is not a problem, at least not a define problem - what is "escape
from an API"? Why you would want to escape from the language you're
writing in?

> Getting gradually rid of those APIs and making them swappable pieces
> simply increases the degree of freedom that we get in our applications,

No, it does not. It increases the number of moving parts, makes the
environment more uncertain, requires more testing and potentially
fragments the ecosystem.

> by having less people rely on stuff like `array_map` and `array_filter`

Why would you want less people to use PHP features? More people should
be using array_map, not less.

> Right, and now they can be built in a way that isn't coupled with the
> engine itself.

It's not coupled with the engine, it's part of the PHP core functions
(which is separate part of PHP from the engine). And I still have to see
one reason why having them implemented in C is a problem. Without having
this reason, the discussion is pointless.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

---

Next page: https://externals.io/message/77854.md?page=2