Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75745
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAEZPtU52X737iUZgKUJbT0bb9z-cr_EYfxMcmv804AhnTpLnhg@mail.gmail.com>
References: <b39ebab3d19d76cda9bafa25919c0e67@mail.gmail.com> <CAEZPtU52X737iUZgKUJbT0bb9z-cr_EYfxMcmv804AhnTpLnhg@mail.gmail.com>
Date: Mon, 21 Jul 2014 10:20:51 +0200
Message-ID: <CAMUwpuQrQd-ROPN0oRk37+U1JFnz487__vZxGjSC5f-TcYyfqg@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Zeev Suraski <zeev@zend.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC: Move phpng to master
From: jpauli@php.net (Julien Pauli)

On Mon, Jul 21, 2014 at 9:52 AM, Pierre Joye <pierre.php@gmail.com> wrote:
> hi Zeev,
>
> On Mon, Jul 21, 2014 at 9:31 AM, Zeev Suraski <zeev@zend.com> wrote:
>> All,
>>
>>
>>
>> As we=E2=80=99re getting closer to release 5.6.0, and given the very hig=
h level of
>> interest in phpng, I think it=E2=80=99s time for us to provide some clar=
ity
>> 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 t=
o
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-Nex=
t.

Julien