Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75974
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.181 as permitted sender)
References: <b39ebab3d19d76cda9bafa25919c0e67@mail.gmail.com> <53CF4146.5080800@sugarcrm.com>
In-Reply-To: <53CF4146.5080800@sugarcrm.com>
MIME-Version: 1.0
Thread-Index: AQI8QOdx/Do9KUTbDGI5HWlFNEg77gLEYnf3mr5B7tA=
Date: Wed, 23 Jul 2014 23:27:59 +0300
Message-ID: <ea7a80e05193b8a055747d8cee88a45f@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] RFC: Move phpng to master
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
> Sent: Wednesday, July 23, 2014 8:00 AM
> To: Zeev Suraski; PHP internals
> Subject: Re: [PHP-DEV] RFC: Move phpng to master
>
> I think before we do that we need to do much better documentation around
> the changes in the engine. I know that in the past we followed the "code
> is
> documentation" pattern, but the code there becomes more and more dense,
> with macros upon macros upon macros, and myriads of micro-optimizations
> which make sense only in specific context. Absent that context and
> documentation, understanding what is going on becomes much harder and so
> becomes dealing with that code. Some of the changes right now are
> partially
> documented in https://wiki.php.net/phpng-int, some (like parameter parsing
> API) not documented at all. Given that, I'm not even sure I understand
> what
> phpng is right now - as I didn't have time to parse every commit during
> active
> development. So it would be nice to have some internal docs if we want
> people to form an informed opinion about what is being proposed.
>
> And, of course, the porting guide for extension authors is another
> required
> part. I know the phpng team did great work porting the extensions, but
> people
> would need to support them and add the new ones, so it is a must.

As Dmitry mentioned, this is something we're going to work on (with primary
focus around the porting guide, and secondary focus on extending the
internals document).

Zeev