Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71482
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADajX4DT_3Z5d9+k5ht7ju97xRBBv3_Ephfr+KXYFDXq=kWTZA@mail.gmail.com>
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>
	<CAF+90c8E6cKh7bt5KDdhxZso=sheNMGyLgdjA+9zckqoOL8jMg@mail.gmail.com>
	<CAEp07h-Ga7oTMn3CQXqHXEAbe8EO6V8adz8joAV8g2DHMd8bpw@mail.gmail.com>
	<CAF+90c-GCkuJsbyh0GA_0Fh6oUOr6-WOJ6_3deb=NA-sSVCODQ@mail.gmail.com>
	<CAEZPtU6HJshvMJVmrxH5QyOasFRD16kRXJ07JH8oHS=iK9i0Sg@mail.gmail.com>
	<52E150CC.8080202@oracle.com>
	<CADajX4DT_3Z5d9+k5ht7ju97xRBBv3_Ephfr+KXYFDXq=kWTZA@mail.gmail.com>
Date: Fri, 24 Jan 2014 07:36:13 +0100
Message-ID: <CAEZPtU4Lcca0oLZAm+1fH1Ggwk7VMQ-kHjP79STajyWET6EAVQ@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: Christopher Jones <christopher.jones@oracle.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length
 and integer
From: pierre.php@gmail.com (Pierre Joye)

On Fri, Jan 24, 2014 at 2:25 AM, Adam Harvey <aharvey@php.net> wrote:
> On 24 January 2014 01:26, Christopher Jones
> <christopher.jones@oracle.com> wrote:
>> Overall
>>  - I'm fine with changes going into, say, PHP 5.7
>>  - I'm fine with the type renaming
>>  - I'd prefer ZPP compatibility was kept
>>  - I'm fine with dropping support for old SAPIs, but I think warning
>>    is needed no matter how unusable they currently are e.g. this means
>>    merging the feature to PHP 5.7
>
> This is pretty much how I feel about this too. As a user, it's
> something I'd like to have, but as a maintainer or developer on a few
> extensions (some PECL, some third party), this isn't something I'm
> terribly excited about having on a few months notice for 5.6 =E2=80=94 it=
's
> going to be an annoying, subtle change for code that has to support
> older versions, as worthwhile as it is in the long term.

The same amount of effort is required for 5.6+int64 changes than with
5.4 or 5.5. This is really easy to migrate. Yes, the zpp question has
to be solved but it should not stop this patch to get in, it is ready,
tested (as much as we can), etc. Delaying its integration will not
help anyone and the same problem will happen in 5.7 or 6. Let alone
the unnecessary wait for a long due change, cleanup and correctness
change, this wait will be even insanely long if we go with 6, both
from an availability (2 years+) and adoption point of view.

I really ask everyone to at least read the migration doc and try it,
with an extension. I did it with my exts (and I have many), and it is
really straightforward and the efforts pay off given the benefits of
this patch.


Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org