Hi Nikita,
On Thu, January 23, 2014 15:29, Nikita Popov wrote:
> 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.
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