Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71815
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.73.107 as permitted sender)
To: Derick Rethans <derick@php.net>
Cc: PHP Developers Mailing List <internals@lists.php.net>, Matt Ficken <mattficken@php.net>, "Stephen A. Zarkos" <szarkos@php.net>
In-Reply-To: <alpine.DEB.2.10.1401302346240.6067@whisky.home.derickrethans.nl>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
	 <alpine.DEB.2.10.1401302346240.6067@whisky.home.derickrethans.nl>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 31 Jan 2014 04:31:46 +0100
Message-ID: <1391139106.6953.118.camel@ghost>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string
 length and integer
From: ab@php.net (Anatol Belski)

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. 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.
> 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? Reverting the semantic changes is a wimp. The effort you're talking
about is a one time action, or can you point to another RFC of such globality?
Without effort even a cat isn't getting born :)
The compatibility path is being developed and improved, and it will be of
course nothing without your as well as everyone's else participation. But
you're right, who cares?

> 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. Would I see that done
berofe I'm retired, or would my grandkids at least? Suppressing things
doesn't improve anything.

Regards

Anatol