Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71851
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <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> <alpine.DEB.2.10.1401311059060.6067@whisky.home.derickrethans.nl>
Date: Fri, 31 Jan 2014 13:30:41 +0200
Message-ID: <CAL0xaBEiKOnRB9NT-98+OfveRWqm18aDBZGeNn=3Mz396s0TwQ@mail.gmail.com>
To: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3dbbc2f229204f14282d3
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--001a11c3dbbc2f229204f14282d3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2014-01-31 Derick Rethans <derick@php.net>:

> 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...mas=
ter
> > >
> > 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 go=
t
> > 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?


I ask you, does it really matter if you have to do it for 5.6 or 6.0? You
have to do it anyway sooner or later. For once, I feel that if I had a
dozen extensions to maintain, I would welcome the ability to spread the
workload between adopting 64 bit support in 5.6 and adopting whatever big
changes will come with 6.0 (and as that is a major versions - there
probably will be _A LOT) of stuff changing).
Sometimes fanatically sticking to the rules of development is not the best
course of action - you have to make exceptions in some cases and try to
adjust the workflow so that you don't end up forcing people to do too much
work at once. Otherwise you end up with slow adoption.


> > 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.
>

There are always some extensions with a much bigger work needed to be done
than the rest. Database extensions are one of the biggest challenges to
convert.


>
> > > 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 updat=
e,
> > > 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!
> > >
> > > 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 ar=
e
> > > forgetting how incredible much pain *all* extension authors have to g=
o
> > > 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=E2=80=94I th=
ink 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.
>

5.3 is in the EOL phase and is not maintained at this point. It's EOL ends
in June. So with 5.6 all you have to maintain is 5.4 to 5.6 . Remember - no
more than 3 branches at one time are supported.

>
> > > 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 (=C3=A0 la "PHP 6") had a usefu=
l
> > > 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=E2=80=94but so would be "consistent function naming" or "case sensi=
tive
> function/method names"=E2=80=94and we're not never going to get these eit=
her.
>

Sorry, it's not a technical dept? As a userland developer, I had my moments
cursing the PHP developers in general for not properly working PHP in 64
bit environment. True, maybe I'm that not so often case of the PHP
developer working with stuff that needs those 64 bit integer (my project
does not work under 64 bit windows properly) to do my calculations because
32 bit integer is too small.

P.S. I want to mention the general trend in the software development of
"fuck 64 bits, it can run in 32 bit mode anyway". And we get what we get -
almost a decade of 64 bit processor availability and half the software
still doesn't not support it properly. This is just a remark.

--001a11c3dbbc2f229204f14282d3--