Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71933
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1391281911.2941.316.camel@guybrush>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
	<52EAF0A3.2000001@oracle.com>
	<1d5850561e0ef9e7739c7e7b7b0448d0.squirrel@webmail.klapt.com>
	<52EC0B34.8080109@oracle.com>
	<d41c0659b516306ea4eb534723f3d771@mail.gmail.com>
	<CAEZPtU6k9cBBcVv7B5MMzmsYJcUROAy4Bsqqu184-dyCCghU7A@mail.gmail.com>
	<1391281911.2941.316.camel@guybrush>
Date: Sat, 1 Feb 2014 20:30:14 +0100
Message-ID: <CAEZPtU6BF5zixmq4egOESBacqNCSSR6NLKN4bxPpePC8zskJRA@mail.gmail.com>
To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>
Cc: Zeev Suraski <zeev@zend.com>, Christopher Jones <christopher.jones@oracle.com>, 
	Anatol Belski <anatol.php@belski.net>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: pierre.php@gmail.com (Pierre Joye)

On Sat, Feb 1, 2014 at 8:11 PM, Johannes Schl=C3=BCter
<johannes@schlueters.de> wrote:
> On Sat, 2014-02-01 at 19:35 +0100, Pierre Joye wrote:
>> It is not, there is no change from user level but on windows and a 1-2
>> other platforms with long being 32 bit in 64bit.
>
> The current rule isn't precise, different interpretations are possible.
> I lean to the side that a big change to the APIs is comparable to a
> userland language change. I can see that this is read differently.


This section of the RFC aims to protect from not well designed
addition to the language, things affecting the long term maintenance
and its core design.

To make the internals implementation and APIs more 64bit aware, safer,
cleaner and easier to deal with 64bit (compilation time check f.e.) is
not something covered by this section.

>> Also I find amazingly disturbing the amount of efforts you are putting
>> to shut down this RFC, without a single comment in the last months or
>> weeks, not even now to explain your vote.
>>
>> I do not mind a no, but what is happening here is disgusting, to say it =
nicely.
>
> Many contributors mentioned their concern about pushing in a patch
> changing more than 20,000 lines of code now.

Stability of this patch has been proven. Work has began for months.
And if you look at the actual changes, they are much less problematic
than a couple of small patches having disturbing releases for ages, or
last minute addition of totally unstable extension, delaying release
and early adoption for months.

>I haven't seen much critic
> on the implementation itself, simply the request for more time to
> a) review it to make sure there are no accidental errors from conversion
> and

99% of the implementation and options about it have been around for
literally months. Sorry, this argument is totally invalid.

> b) time to learn "the new way" before putting in a release, many have to
> relearn thins hardwired in the brain for more than 10 years, such
> adoption takes some time.

I don't think anyone with little C experience needs more than 15mins
to understand the changes, given the extensively verbose and migration
guide.


> Yes, we might have reviewed the branch sooner and learned the details
> sooner but we are lazy and holding back in investing time in
> "experimental" things.

There is nothing experimental in this patch but a long awaited due
cleanup and safe changes. We have been talking about that for ages.
Our team finally took the beast by its horn and put a working, clean
and safe patch. They tested it, very early, constantly, provided
regular updates and requested feedback since months. I, personally, do
not buy the laziness and lack of time argument.


> I think a good way to proceed is to put it in master now and leave it
> from 5.6. This forces everybody to look into it (and we will have lots
> of opportunity to learn due to merging pain [which we have when putting
> in 5.6, too]) and gives everybody enough time to adopt their brain and
> prepare pecl (and internal) exts.

That won't happen without another RFC and votes. We also drop all the
options as we are most likely targeting 6 anyway. I won't be surprised
to see the same arguments coming again btw :)


Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org