On 13 October 2014 21:37, Stas Malyshev wrote:

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

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



Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 24 of 29 | next ›
Discussion Overview
groupphp-internals @
postedOct 10, '14 at 8:28p
activeDec 1, '14 at 7:22a



site design / logo © 2019 Grokbase