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

On Fri, 31 Jan 2014, Anatol Belski wrote: > On Fri, 2014-01-31 at 00:56 +0100, Derick Rethans wrote: > > On Mon, 27 Jan 2014, Anatol Belski wrote: > > > > > https://wiki.php.net/rfc/size_t_and_int64 > > > > > > There was two big questions regarding the compatibility. Those open > > > questions appeared in the discussions are reflected in the reworked RFC. > > > > 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 > > > I never said that were the full worky port. I did that in 2 hours as it > was asked to be done on some extension, and you know that. It can be got > ready in several days. "Several days" for one extension. Imagine that you maintain a dozen. Are you really expecting that people will like it to have to spend a month porting all their extensions for such a marginal benefit? And that for a *minor* release? > So I've chosen this as an example on what the effort could be. Should > I have taken an easy one with 5 minutes effort, like scream? But you > prefer to interpret some complex case as an average one. Seriously, the MongoDB extension isn't that complicated. There are a lot of methods, but no different from any other database extension. > > 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! > > > > And what is the gain? Absolutely nothing important. Who cares whether > > you can have 2147483648 or 9223372036854775808 byte long strings? Or > > whether some silly OS doesn't implement 64bit ints. Seriously, you are > > forgetting how incredible much pain *all* extension authors have to go > > through. This is not only ext/ or pecl/ or people hosting things in > > GitHub, but also an enormous amount of internal extensions for > > companies. > > So with next major you mean you would abandon the 5.x support in your > exts, as it's too much? No, absolutely not. Right now, we have to support 5.2 to 5.6—I think I even support 5.1 for Xdebug. But with this change, the 5.6 compatible code is drastically different from the 5.2-5.5 ones. > > No, there is way too little benefit here to push that gigantuous > > amount of work on developers, for zero to no gain. Atleast the > > introduction of a unicode string type (à la "PHP 6") had a useful > > meaning. > > > > I can't believe any sensible developer would vote to add this now > > into 5.6. > > It was started to have it consistent overall. The next step after it > were the performance improvement on 64 bit. Then one could think about > the dependency libs improvement. To whose costs goes this delay? > Technically, as well as socially. Just because it's not getting done. > It is a technical debt which is growing every day. Uhm, the current situation works just fine. I wouldn't call this technical debt. I am also not saying that this branch is not a good thing—but so would be "consistent function naming" or "case sensitive function/method names"—and we're not never going to get these either. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine