Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74164
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <53732673.3080106@lsces.co.uk>
References: <e5f19ac0089d24adc695fce93ad9bd9c.squirrel@webmail.klapt.com>
	<CA+9eiLuoJM5bwA46M_2YddTXYOhAwhii=9Ref7-NNeuRuBfW5A@mail.gmail.com>
	<CAEZPtU7zz=npjUhacwSBA6cz+kb9iBmn3fjkvYuAjqtiPQgJhw@mail.gmail.com>
	<CAF+90c9J5mtTzqFxvQHka5w5zVoGOzXNaUeYec62X_LYLOPcxA@mail.gmail.com>
	<CAEZPtU6L0TCyR+U-eEJnwfYbxfMRibpKB70_Ue5fTOHD4y_VAQ@mail.gmail.com>
	<53732673.3080106@lsces.co.uk>
Date: Wed, 14 May 2014 10:22:49 +0200
Message-ID: <CAH-PCH5b3wdu3vERp+LTnoSSs2_cX5wNy6hZc6MK6TPiBZDpRw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c152f4cc9e5404f957e272
Subject: Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string
 length and integer
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c152f4cc9e5404f957e272
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 14, 2014 at 10:16 AM, Lester Caine <lester@lsces.co.uk> wrote:

> On 14/05/14 06:46, Pierre Joye wrote:
>
>> Independently of that: In a lot of the previous discussion people have
>>> many,
>>> >many, many times asked that this patch be implemented without all thos=
e
>>> >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 PH=
P
> 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 th=
e
> need for a vote on a 'detail that can be changed'? It's the detail elemen=
ts
> that need to be agreed on ... not the principle of 64bit!
>
> Hopefully there is no plan to backport this to the PHP5 builds?
>
>
both the phpng and the size_t rfcs are targetting the next major version,
none of them are accepted yet, both of those would/will be suitable for
'home users'.
buth these are all public information, stated in the RFCs and discussed on
internals@ which you seems to be subscribed on based on your replies to the
list, so I'm not sure where the confusion comes from.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c152f4cc9e5404f957e272--