On Mon, Jul 21, 2014 at 9:52 AM, Pierre Joye <pierre....@gmail.com> wrote: > hi Zeev, > > On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski <z...@zend.com> wrote: >> All, >> >> >> >> As we’re getting closer to release 5.6.0, and given the very high level of >> interest in phpng, I think it’s time for us to provide some clarity >> regarding what happens post 5.6.0. >> >> >> >> Dmitry and I wrote an RFC proposing that we merge phpng into master and >> turn it into the basis of the next major version of PHP (name TBD). >> >> >> >> The RFC is available at https://wiki.php.net/rfc/phpng >> >> >> >> Some supporting links available down below. >> >> >> >> Comments welcome! > > Quoting Dmitry's mail from last week "phpng is an experimental > branch", as such, I see no appealing reasons to replace master with > phpng and use phpng as base for the next major version. I am not > really surprised by this request, despite contradictory comments about > this exact point in the past few weeks. > > Despite the excellent performance improvements, it is by far not ready > to be used as base for the next major release, the release we will > have to maintain for the next decade. There is almost no > documentation, the APIs are not clean or inconsistent (just came back > home, will provide details later) but having two separate zpp, same > area's functions mixing use of zend_char and char (creating hard to > catch bugs, not always catch-able at compile time f.e.), no (known) > plan about when the experiments will stop and when or how deep the > cleanup will be done. > > In other words, I cannot agree to replace master with phpng, not with > its current state and it is definitively not what I could imagine as a > base for php-next. A roadmap, undocumented and plan-less development > (sorry, but stacking up a couple of % performance improvement has > little to nothing to do with designing php-next) is the best way to > fail to have what many of our users and developers could expect for > php-next. > > Cheers, > -- > Pierre
Hi I can only agree here. I'd like a clean API. We need to consider PHP-Next jump as an opportunity to clean our API and finally have something understandable for a newcomer, and documented. That's a move nobody dared to take in the last decade, degrading more and more our codebase in term of understandability and flexibility. This can't last Old features and unused things should be cleaned up. Quickly caught, impacting the engine : - Resources are a hell, mixed with zend_lists etc... inconsitstent and absolutely PITA to develop with. - Streams need to be cleaned up and reworked to support full asynchronous IOs, which could involve threads, thus engine tied - Signals have been worked on starting with 5.4 (AFAIR), but never activated by default. I guess the actual implementation lacks a bit more reflection to be stable, and to finally propose signal managers into userland. ext/pcntl should be somehow merged to core, and this as well would involve engine work - TSRM need to find love, or to find a better replacement, which would involve a big engine work as well - ... and so on Macro hell should be reworked as inlined functions, and I'd like we start supporting C99 as well. Performance is a userland point. API, doc, and clean things are developers points, and IMO, they are as important. What about merging OPCache to the branch ? This was talked about at PHP5.5 release, has never happened yet, and doesn't seem planed. This could have a big impact on the engine codebase. I just cant believe we won't rework our API , fully and deeply, for PHP-Next. Julien -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
