Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71439
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52E0F55F.4040802@lsces.co.uk>
References: <fa05c43bc2fff5420759e05dee19c99f.squirrel@webmail.klapt.com>
	<CAF+90c8mDBqe+E=cWxpD-U48Ho0QV3iHiwS9pOSEbUn_uZTVnQ@mail.gmail.com>
	<CA+9eiLvhRqFAunM8GCpqE5ja2jXKCzFMKdtF0NkBT11nu=36MQ@mail.gmail.com>
	<CAEZPtU7-mBoXcsvXQvD42uG58KKKLY3TJL=aV5uqcGEFhE3PKQ@mail.gmail.com>
	<CAEZPtU7vJDEyZAeCPR3j7_4+HL-4iCMUd3+Xa94xzg7xe1Z91Q@mail.gmail.com>
	<52E0F55F.4040802@lsces.co.uk>
Date: Thu, 23 Jan 2014 15:29:47 +0100
Message-ID: <CAF+90c8E6cKh7bt5KDdhxZso=sheNMGyLgdjA+9zckqoOL8jMg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01634ec2d162e404f0a4129b
Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length
 and integer
From: nikita.ppv@gmail.com (Nikita Popov)

--089e01634ec2d162e404f0a4129b
Content-Type: text/plain; charset=ISO-8859-1

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

--089e01634ec2d162e404f0a4129b--