Independently of that: In a lot of the previous discussion people have many,
many, many times asked that this patch be implemented without all those
macros renames and zpp changes. I still have a hard time seeing the benefit
of doing that. The zpp changes also conflict with phpng, because S has a
different meaning (and imho for no good reason - it could just as well stay
at s).
This can be adapted, this is a details. It is also why I have tried
to get phpng and this patch along together and get both teams work
together. Cooperation in this case will be benefit for php as a whole
as more optimization can be achieve while keeping the safe&clean
implementation.
As of now, phpng has been worked on for the last months, totally
privately. And even if it looks promising it is still not remotely
ready to be actually proposed. However it does not prevent you to use
it to stop other improvements, which have been worked on for months,
publically, with continuous tests, status updates, etc. I am not sure
what is happening here is good for PHP.
My personal impression is that phpng is yet another independent port of php just like HHVM and the like. These all target a particular area of PHP use and may not be suitable for 'home users'. As an alternative base for PHPNext it may have a better pedigree and to that end a decision needs to be made for the path forward. What seems totally out of place here is a vote on something which has no real target yet? Has phpng already been accepted as PHPNext? That PHPNext will be 64bit is a given? So what is the need for a vote on a 'detail that can be changed'? It's the detail elements that need to be agreed on ... not the principle of 64bit!
Hopefully there is no plan to backport this to the PHP5 builds?