On Mon, Jul 21, 2014 at 9:52 AM, Pierre Joye wrote:
hi Zeev,
On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski wrote:

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


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

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

I just cant believe we won't rework our API , fully and deeply, for PHP-Next.


Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2018 Grokbase