Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71811
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.75 as permitted sender)
Message-ID: <52EAF181.3000907@sugarcrm.com>
Date: Thu, 30 Jan 2014 16:42:41 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Derick Rethans <derick@php.net>, Anatol Belski <ab@php.net>
CC: PHP Developers Mailing List <internals@lists.php.net>, 
 Matt Ficken <mattficken@php.net>,
 "Stephen A. Zarkos" <szarkos@php.net>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com> <alpine.DEB.2.10.1401302346240.6067@whisky.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.10.1401302346240.6067@whisky.home.derickrethans.nl>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: smalyshev@sugarcrm.com (Stas Malyshev)

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...master
> 
> 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 — 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. 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. 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.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227