Re: [VOTE] 64 bit platform improvements for string length and integer

Hi all, On Fri, Jan 31, 2014 at 9:42 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote: > > 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. Once code is updated, then it's a matter of including compatibility header for older PHP, is't it? However, it's requires many line of changes. Personally, I don't mind it at all, though. Although, I would like to see it soon. It may be better to introduce it from 6 and start 6 branch now. Even if we choose this path, it would be better provide new type and macro definition to PHP 5.x for 3rd party modules. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net