On 21 Jul 2014 10:21, "Julien Pauli" <jpa...@php.net> wrote: > > 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.
I don't think that a cleanup is nearly as important as php-ng is as we stand currently. The will be no mercy from the competition. We can start reworking the API when it hit master.
