On Wed, May 14, 2014 at 10:53 AM, Dmitry Stogov <dmitry@zend.com> wrote:
phpng is based on the same sources and 99% compatible.
You surely meant 99% incompatible right?
It changes literally every single line of code related to hashtable,
zval or related areas. It adds dozen of possible issues not easily
catch-able because of types change for numerous widely used APIs,
besides being inconsistent (yet, that's on the todos).
We are just changing the basement.
it must be the basement for PHPNext, but we didn't start any discussions
about that.
No, it is one task for php-next, one upcoming RFC (well, more in a few
months than next week).
We actually have a lot of work to do and spend most the time doing our best.
We have no plans to backport it into PHP-5.6.
So we do, and we do it now for phpng as well. As coop is the only way to go.
PHP supports 64bit for ages, and this proposal has nothing common with
64bit support in general.
This statement is wrong, you know it. I may re post common good
practices and recommendations for actual 64bit support but that will
be doubled.
It allows 2GB strings, but do you imagine a web application that need them?
As I already said numerous times, 2GB+ is a side effect, not a goal.
However, each big PHP site will have to "pay" for it.
and how many times do we have to pay for Zend total lack of clue about
open processes and communications?
Pierre, you are getting the things wrong. Changing the types is straightforward thing to do so an open branch. What the Zend guys did was try and see approach with their ideas. If the results were bad you would have probably never heard of phpng. This kind of things sometimes are not open from the very beginning to limit the noise.
I hope I'm wrong but you are probably hurt because the size_t patch did not get accepted and somehow now phpng gets lot of attention.