Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71839
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Fri, 31 Jan 2014 11:06:01 +0000 (GMT)
To: Anatol Belski <ab@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: <1391139106.6953.118.camel@ghost>
Message-ID: <alpine.DEB.2.10.1401311059060.6067@whisky.home.derickrethans.nl>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>  <alpine.DEB.2.10.1401302346240.6067@whisky.home.derickrethans.nl> <1391139106.6953.118.camel@ghost>
User-Agent: Alpine 2.10 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1203584705-1391166361=:6067"
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: derick@php.net (Derick Rethans)

--8323329-1203584705-1391166361=:6067
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Fri, 31 Jan 2014, Anatol Belski wrote:

> On Fri, 2014-01-31 at 00:56 +0100, Derick Rethans wrote:=20
> > On Mon, 27 Jan 2014, Anatol Belski wrote:
> >=20
> > > 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 R=
FC.
> >=20
> > 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...m=
aster
> >=20
> 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=20
you really expecting that people will like it to have to spend a month=20
porting all their extensions for such a marginal benefit? And that for a=20
*minor* release?

> So I've chosen this as an example on what the effort could be. Should=20
> I have taken an easy one with 5 minutes effort, like scream? But you=20
> prefer to interpret some complex case as an average one.

Seriously, the MongoDB extension isn't that complicated. There are a lot=20
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 =E2=80=94 especially not so late in the game for 5.6!
> >=20
> > 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=20
> exts, as it's too much?

No, absolutely not. Right now, we have to support 5.2 to 5.6=E2=80=94I thin=
k I=20
even support 5.1 for Xdebug. But with this change, the 5.6 compatible=20
code is drastically different from the 5.2-5.5 ones.

> > No, there is way too little benefit here to push that gigantuous=20
> > amount of work on developers, for zero to no gain. Atleast the=20
> > introduction of a unicode string type (=C3=A0 la "PHP 6") had a useful=
=20
> > meaning.
> >=20
> > I can't believe any sensible developer would vote to add this now=20
> > into 5.6.
>
> It was started to have it consistent overall. The next step after it=20
> were the performance improvement on 64 bit. Then one could think about=20
> the dependency libs improvement. To whose costs goes this delay?=20
> Technically, as well as socially. Just because it's not getting done.=20
> It is a technical debt which is growing every day.

Uhm, the current situation works just fine. I wouldn't call this=20
technical debt. I am also not saying that this branch is not a good=20
thing=E2=80=94but so would be "consistent function naming" or "case sensiti=
ve=20
function/method names"=E2=80=94and we're not never going to get these eithe=
r.

cheers,
Derick

--=20
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
--8323329-1203584705-1391166361=:6067--