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

From: Date: Thu, 30 Jan 2014 23:56:23 +0000
Subject: Re: [VOTE] 64 bit platform improvements for string length and integer
References: 1  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
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

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.

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.

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


Thread (132 messages)

« previous php.internals (#71809) next »