Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75755
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.180 as permitted sender)
MIME-Version: 1.0
Sender: mike.php.net@gmail.com
In-Reply-To: <CAMUwpuQrQd-ROPN0oRk37+U1JFnz487__vZxGjSC5f-TcYyfqg@mail.gmail.com>
References: <b39ebab3d19d76cda9bafa25919c0e67@mail.gmail.com>
	<CAEZPtU52X737iUZgKUJbT0bb9z-cr_EYfxMcmv804AhnTpLnhg@mail.gmail.com>
	<CAMUwpuQrQd-ROPN0oRk37+U1JFnz487__vZxGjSC5f-TcYyfqg@mail.gmail.com>
Date: Mon, 21 Jul 2014 11:37:09 +0200
Message-ID: <CALJZF3it7g44eupRqm_kqygx-=LtxPuvDRSKfjLz4auN1k31vA@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Pierre Joye <pierre.php@gmail.com>, PHP Internals <internals@lists.php.net>, 
	Zeev Suraski <zeev@zend.com>
Content-Type: multipart/alternative; boundary=001a11345984e013cd04feb0d9a1
Subject: Re: [PHP-DEV] RFC: Move phpng to master
From: mike@php.net (Michael Wallner)

--001a11345984e013cd04feb0d9a1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 21 Jul 2014 10:21, "Julien Pauli" <jpauli@php.net> wrote:
>
> 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 h=
igh
level of
> >> interest in phpng, I think it=E2=80=99s time for us to provide some cl=
arity
> >> regarding what happens post 5.6.0.
> >>
> >>
> >>
> >> Dmitry and I wrote an RFC proposing that we merge phpng into master an=
d
> >> 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.

--001a11345984e013cd04feb0d9a1--