Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71456 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 85177 invoked from network); 23 Jan 2014 19:16:06 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jan 2014 19:16:06 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.54 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.215.54 mail-la0-f54.google.com Received: from [209.85.215.54] ([209.85.215.54:59549] helo=mail-la0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2A/19-39789-57A61E25 for ; Thu, 23 Jan 2014 14:16:06 -0500 Received: by mail-la0-f54.google.com with SMTP id y1so1858238lam.27 for ; Thu, 23 Jan 2014 11:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lTwP2wGrRHDwP1/qwZ0bQd5R0qFta0YG3etHKzT5Sm4=; b=ZiZlIe91ZLJjK11uoG5R2Qvb1fcpFoeyGemSsRwo3tehdhfelvH3wj/DUjUPUcI/BK tQlvOAD8uzNd2lVAmCa7MndyGK24JGQSJP1wJSuTn8XTZVpV2BRJqwP84OymeJLHrY6C ZJdEv6Px2xZVgtnkyMb4ZJqoeEY/EVK5MCWK8b+Xn8GpVng1DD1MsxWIIkHyxmAUq1AP BcAJFlDeaQtMjg8o1jQ9hELulQAI6iUzwJc53WMczW4o67d/bLCf5LKhnOSz1eNhLodD IszioIiiYELGGsiN4RI9jC1XW59jgJ/PzeOoAR2/vr/yUk950TOT5Si0SEonntIFTAzy VlJA== MIME-Version: 1.0 X-Received: by 10.152.180.228 with SMTP id dr4mr6263675lac.32.1390504563071; Thu, 23 Jan 2014 11:16:03 -0800 (PST) Received: by 10.112.35.134 with HTTP; Thu, 23 Jan 2014 11:16:02 -0800 (PST) In-Reply-To: References: <52E0F55F.4040802@lsces.co.uk> <2490044a0e2cba88044cf5da9b1b6647.squirrel@webmail.klapt.com> Date: Thu, 23 Jan 2014 20:16:02 +0100 Message-ID: To: Hannes Magnusson Cc: Anatol Belski , Nikita Popov , Lester Caine , PHP internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length and integer From: pierre.php@gmail.com (Pierre Joye) On Thu, Jan 23, 2014 at 7:38 PM, Hannes Magnusson wrote: > On Thu, Jan 23, 2014 at 9:52 AM, Anatol Belski wrote: > >>> 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 :) >> > > > If zpp/error_docref/*printf compatibility is not kept it will take a > long time to update pecl extensions, and risk epic failure in the > future when continuing the work on the extensions > > zpp (COMPAT ? "zyx" : "xyz", &foo, &bar, &baz) will in 1year turn into > zpp (COMPAT ? "zyx|xz" : "xyz|z", &foo, &bar, &baz, &meh) and work > just fine.. until you hit the perfect storm > > > Its easy to migrate php-src exts since they don't have to care about > compatibility with multiple php versions, but needing to support 5.3, > 5.4, 5.5, 5.6, 5.7, 6.0 in a pecl extension will be nightmare > > Also, keep in mind most developers priority is not to work on > supporting unreleased versions of PHP, but to keep maintaining the ext > and adding features - so even though the guesstimate 5months "until > final" is true, the extensions won't be updated until 5months _after_ > 5.6.0 is out. We have ported many extensions (all actively used and maintained) for 5.5.0 before it was released. Some bugs appeared when used with 5.5 and was discovered after final, but that's expected and nothing we can do about it but test, test and test :) That's why I do not really buy this argument to be used against this RFC for 5.6, as if not 5.6, it will be the same with 5.6 and even worst for the hypothetical 6. -- Pierre @pierrejoye | http://www.libgd.org