Re: [RFC] 64 bit platform improvements for string length and integer

On Thu, Jan 23, 2014 at 11:56 AM, Lester Caine <lester@lsces.co.uk> 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. 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 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... 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. Nikita