Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71450 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67227 invoked from network); 23 Jan 2014 17:52:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jan 2014 17:52:25 -0000 Authentication-Results: pb1.pair.com smtp.mail=ab@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=ab@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender) X-PHP-List-Original-Sender: ab@php.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:50429] helo=klapt.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 79/45-39789-6D651E25 for ; Thu, 23 Jan 2014 12:52:24 -0500 Received: by klapt.com (Postfix, from userid 33) id 8168D23D60EC; Thu, 23 Jan 2014 18:52:19 +0100 (CET) Received: from 178.10.239.203 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Thu, 23 Jan 2014 18:52:19 +0100 Message-ID: <2490044a0e2cba88044cf5da9b1b6647.squirrel@webmail.klapt.com> In-Reply-To: References: <52E0F55F.4040802@lsces.co.uk> Date: Thu, 23 Jan 2014 18:52:19 +0100 To: "Nikita Popov" Cc: "Lester Caine" , "PHP internals" Reply-To: "Anatol Belski" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length and integer From: ab@php.net ("Anatol Belski") Hi Nikita, On Thu, January 23, 2014 15:29, Nikita Popov wrote: > On Thu, Jan 23, 2014 at 11:56 AM, Lester Caine > wrote: > > >> Pierre Joye wrote: >> >> >>> I think we can clear these questions during the vote phases, as >>> options. >>> >>> If anyone has an idea how to keep the advantage brought by the >>> renaming (compile checks, clarity, code correctness) without actually >>> doing the renaming in extensions, please fire it:) >>> >> >> Is this still being put forward for a PHP5.x build? Surely this along >> with a tidy up on base modules that support it would be much better used >> as a base for a new PHP6 plan? Extensions that do not support it can >> also be left out and we have a clean demarcation. >> > > I agree with Lester (for once ^^). I think this change is too large for > PHP > 5.6. While the releaseprocess RFC does not guarantee compatibility of our > internal APIs, it does say that source compatibility *should* be preserved > for minor versions. Until now we stuck with that rule: Every minor > release a few APIs are changed, but "few" usually means something like > three or four, not five hundred. But the "a few rule" is a subset of "src compatibility should be kept if possible, while breakages are allowed". That just means there was no such big patches yet, and the actual "rule" was never fully exploited. > If this patch is included in PHP 5.6 I think it is very likely that many > extensions will not be updated or take a long while in updating. It's one > thing to add two or three new ifdefs to support a new PHP release and > something entirely else to change virtually all types in your code and > verify that it is still safe with the new sizes. I think it depends on how active an extension is supported and developed. For instance on PECL are still some extensions not even been ported to PHP5. From the todays experience, a port to the current patch might take from 3 hours to 3 days, depending on complexity. Say 3 days vs 5 months until final, together with the porting docs and tools, most of the really active and being in demand extensions will be so far or users will tear the devs apart :) > I remember how lack of proper APC support was seen as a major problem > with adoption of PHP 5.4 - now imagine how lack of support by nearly all > extensions would look like... It would be interesting to have some data, how much 5.5 is used nowadays. But generally it's not correct comparing APC with all extensions, as APC is a very special case diving so deep into core. Porting of a normal extension wrapping or not a library is much easier. > As such I think that PHP 6 is a better place for this patch. PHP 6 will > presumably also clean up / change many other internal APIs, so we can have > all the major internal (and external ^^) breakage in one release. At > that point it might also make sense for many people to support separate > versions of extensions for PHP 5 and 6 to avoid the ifdef-hell. > What I'm really afraid of hearing "PHP6" is the assotiation with the golem of the previous flop :) There are still trails of PHP6 macros in the sources and extensions. Like "in PHP6 everything will be much better", but really and when? PHP6, when it comes, will face the same compatibility and stability issues which will need solutions. Or even more, if it'll have all possible breakages. On the other hand, instead of having just 2 years of merge headaches, it's just moved to some undefined point in time with undefined amount of merge headaches. And at the end, will the golem come to life? IMHO the best way to stabilize a software is by using it. No offense meant, but that's what I'm really afraid of. Regards Anatol