On Fri, Jan 31, 2014 at 1:42 AM, Stas Malyshev <[email protected]> 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