Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71843
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52EAF181.3000907@sugarcrm.com>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
	<alpine.DEB.2.10.1401302346240.6067@whisky.home.derickrethans.nl>
	<52EAF181.3000907@sugarcrm.com>
Date: Fri, 31 Jan 2014 12:15:40 +0100
Message-ID: <CAEZPtU4XgaYk4N=vBOYBOQD65JiU1RRtxViWmn06SRb90-b8iA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Derick Rethans <derick@php.net>, Anatol Belski <ab@php.net>, 
	PHP Developers Mailing List <internals@lists.php.net>, Matt Ficken <mattficken@php.net>, 
	"Stephen A. Zarkos" <szarkos@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 Fri, Jan 31, 2014 at 1:42 AM, Stas Malyshev <smalyshev@sugarcrm.com> wro=
te:
> Hi!
>
>> Okay, so I've just looked at your attempt to port the MongoDB driver to
>> the "size_t" branch:
>> https://github.com/weltling/mongo-php-driver/compare/mongodb:master...ma=
ster
>>
>> And seriously, this one of the biggest mistakes I've seen in a while.
>> Changing APIs so much that basically half of your code needs an update,
>> or #ifdef hell. This is not acceptable, especially not for a PHP 5.X
>> branch =E2=80=94 especially not so late in the game for 5.6!
>
> Yeah, I looked at that patch and also at the diff between what
> replace.php produces and what is the end result, and it kind of worries
> me.

There is a massive misunderstanding about the options provided in the votes=
.

If the option #2 and #3 are accepted, only, I repeat, only the
declarations of the variables used by zpp have to be changed, nothing
else, no #ifdef, etc.

Obviously codes relying on the size of the variable storing the length
of a char/buffer have to be changed or adapted as well, same goes for
64bit code on non linux platforms, or platforms having long not being
8 bytes on 64bit builds. The only other parts is the array index and
stat operation, but these are not related to the option #2 and #3 and
have to be done anyway already if one cares about LFS.

> Especially the part when you have to manually update all the types
> and how easy it is to miss one.
>  Not sure, if this is solved
> automatically then I might be overreacting but right now it looks like
> I, for example, have been underestimating the amount of code disruption
> this is causing.

It can be automated for zpp, it is almost the case already and Anatol
is working on this part to fully automate zpp changes (with option #2
and #3).


> I think refactoring PHP types and cleaning them up is a
> good idea, but it also means I can't recommend 5.6 adoption to anybody
> for years after the release, after we're sure extensions that were
> disrupted are stable again. And we're not on stellar numbers with 5.5
> adoption now, even given 5.4 to 5.5 supposed to be pretty much smooth
> ride unless you mess with opcodes.
>
> Again, I'm not against the idea of the patch or the implementation, but
> looking at how much work it seems to take for ext author, I'd say it may
> be a good start for PHP 6 branch.

I will prepare a sample ext compiling using 5.3, 5.4, 5.5 and with the
int64 branch, it will be a better example than what we can see in
mongodb, which does not use option #2 and #3. It is basically bad as
many of us only focus on this constellation and totally ignore these
options which were added as a possible very good compromise.

Cheers,
--
Pierre

@pierrejoye | http://www.libgd.org