Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71793 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98374 invoked from network); 30 Jan 2014 10:27:03 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 30 Jan 2014 10:27:03 -0000 Authentication-Results: pb1.pair.com header.from=arvids.godjuks@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=arvids.godjuks@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.43 as permitted sender) X-PHP-List-Original-Sender: arvids.godjuks@gmail.com X-Host-Fingerprint: 209.85.216.43 mail-qa0-f43.google.com Received: from [209.85.216.43] ([209.85.216.43:39558] helo=mail-qa0-f43.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AB/7B-42724-6F82AE25 for ; Thu, 30 Jan 2014 05:27:02 -0500 Received: by mail-qa0-f43.google.com with SMTP id o15so4054639qap.16 for ; Thu, 30 Jan 2014 02:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=O3FD0pyauOuCQ1ysLcmsUPJtkAc8T5yH0qmss+Mx9GQ=; b=yRjFa3TaRpEyG9jW4QFk8iyj36H6ICPXaCdKRohyYe14Iwc4DySP/6uP5jLxHjAN1B a3bhc04ZcHCUKoNMh7AQEA6QwS/44RhG9k7odfKZUwsczhsEQP4Eez/03vSyS8M+FXwq pe59LTHcLHe0F5FcEZPmyT+ViKncWAShhGECRsV1QXfVgiDvdc+kZeepBiTE+M+tDHWT 5d88z3pM6iJ8MPyFVbnD8qnxD/W0RoTiVexohTk86xZsjSAeqbVx++GUbdonCHbn6GpE zHCpn5aRqtDx8Ahc46Gem9D/lHwAqXeGqtef/9NFxpnsqVBY0723aKyknSzIWM0aArYU oDlw== X-Received: by 10.229.171.8 with SMTP id f8mr20212160qcz.13.1391077619508; Thu, 30 Jan 2014 02:26:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.97.182 with HTTP; Thu, 30 Jan 2014 02:26:39 -0800 (PST) In-Reply-To: References: <52E8C097.6080208@lsces.co.uk> Date: Thu, 30 Jan 2014 12:26:39 +0200 Message-ID: To: PHP internals Content-Type: multipart/alternative; boundary=001a11c3a9845dc6d204f12d7f06 Subject: Re: [PHP-DEV] some thoughts about php 6 From: arvids.godjuks@gmail.com (Arvids Godjuks) --001a11c3a9845dc6d204f12d7f06 Content-Type: text/plain; charset=UTF-8 On the subject of 64-bit improvement, there was an argument to wait until PHP6 so that extension maintainers had to deal with one extension conversion, but a more broad one (because there will be other things changing). I actually think it is not such a great idea, because when dealing with multiple things to update, it is far easier to break something or mess it up. I want to point out, that although the adoption of PHP picked up the pace, new versions are not adopted that fast. Many leaped over 5.4 to 5.5 because 5.4 does not have a working opcode cache and that is a major no go for almost everyone. Nethertheless, when PHP 6 is released, many will leap from 5.3 or 5.5 straight to it. 5.6 can be a kind of grace period to port and test the extensions, so the majority of them is updated when PHP 6 comes. This will also spread the workload and give a chance for everyone to catch up with the 64 bit support. As part of this effort, there has to be an informational campaign to inform people that extension developers have to convert them. This has to be shown clearly and loudly (php.net front page pinned announcement with linkage to the explanation of what the heck is going on, also we should announce it all on any other channels that are out there). On the case of concerns of Yahoo and alike - it does not really matter, because they have to do this work anyway - sooner or later, but the amount of the required work does not change. Actually, if you cram too many changes in a single release (PHP 6), you end up with even bigger workload, because now you have to implement 64 bit support and other PHP 6 compatibility things - you end up in a state when for extension to work, you have to do all the changes at once without the ability to separately test if you 64 porting was done correctly. You end up with multiple changes in one place and have to debug them all simultaneously. The fact, that some companies still stick with 5.3 and don't update their own code base does not concern the PHP developer team. It does not matter if you do 64 bit support in 5.6 or 6.0 - Yahoo has it's own schedule and they might migrate from 5.3 to 5.5 (well, because 5.4 has issues with opcode cache - it's understandable to skip it over) and that plan may be already in motion. So it will not matter for them if 5.6 has 64 bit support or not. They might just wait for the PHP 6 after 5.5 (and it kind'a makes sense). So, I say you go with the 64 bit improvements for 5.6, set all the things in motion, do the porting docs and make a hell lot of noise about this. I'm willing to help with the information campaign, because this lack of proper 64 bit support has gave me a few "WTF?!" situations when I had to figure out why things do not work and realize it's due to the 64 vs 32 bit issues. Arvids. --001a11c3a9845dc6d204f12d7f06--