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