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

On Fri, Jan 31, 2014 at 1:42 AM, Stas Malyshev <smalyshev@sugarcrm.com> wrote: > 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. 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