Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71831 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 43446 invoked from network); 31 Jan 2014 08:51:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Jan 2014 08:51:04 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; 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:60062] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 66/80-39593-4F36BE25 for ; Fri, 31 Jan 2014 03:51:02 -0500 Received: (qmail 23153 invoked by uid 89); 31 Jan 2014 08:50:57 -0000 Received: by simscan 1.3.1 ppid: 23147, pid: 23150, t: 0.0620s 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; 31 Jan 2014 08:50:57 -0000 Message-ID: <52EB6487.2050502@lsces.co.uk> Date: Fri, 31 Jan 2014 08:53:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] int64/size_t options votes clarification From: lester@lsces.co.uk (Lester Caine) Pierre Joye wrote: > In the case this RFC is rejected for 5.6, these options are really not > what is planed to do for 6.x as we should do it the clean way, as > explained in the various discussions here and as many of the > opposition used as argument as well. See next ... > For those having voted no for 5.6 and the options, would you mind > explaining what are your wishes? It will help to move forward, no > matter the outcome of the votes. Are you really saying that this is just a hack to get 5.6 working and that it will all require re-working in PHP6? I'm not particularly bothered what you do with 5.6 myself and I'm sure a lot more 'users' are probably in the same boat. It will still be a few years before I've managed to get everything up to PHP5.4 and by then hopefully we will have PHP6 with a nice clean Unicode base ( which in itself I think requires dropping case insensitivity ) and a nice clean 32/64 bit operational switch. Yes there will still be a large number of 32bit only machines around so PHP6 will have to work transparently with them! Basically I can't see any point wasting time on PHP5.6 at all. Except as a springboard to 'for 6.x as we should do it the clean way'! The usage figures show just how important the current builds are and I'm not seeing any reason to bother with 5.5 currently either ... -- 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