Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74161 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48825 invoked from network); 14 May 2014 08:13:49 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 May 2014 08:13:49 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:34292] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7A/51-40033-CB523735 for ; Wed, 14 May 2014 04:13:48 -0400 Received: (qmail 14808 invoked by uid 89); 14 May 2014 08:13:45 -0000 Received: by simscan 1.3.1 ppid: 14801, pid: 14804, t: 0.0842s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 14 May 2014 08:13:45 -0000 Message-ID: <53732673.3080106@lsces.co.uk> Date: Wed, 14 May 2014 09:16:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: PHP internals References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string length and integer From: lester@lsces.co.uk (Lester Caine) 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 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? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk