On 13 October 2014 21:37, Stas Malyshev <smalys...@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/
