Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71869
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hristov.com from 91.196.124.214 cause and error)
Message-ID: <52EB9CF7.3000802@hristov.com>
Date: Fri, 31 Jan 2014 14:54:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: internals@lists.php.net
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> <CAL0xaBEiKOnRB9NT-98+OfveRWqm18aDBZGeNn=3Mz396s0TwQ@mail.gmail.com>
In-Reply-To: <CAL0xaBEiKOnRB9NT-98+OfveRWqm18aDBZGeNn=3Mz396s0TwQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: php@hristov.com (Andrey Hristov)

On 31.01.2014 13:30, Arvids Godjuks wrote:
> 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...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?
>
>
> 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.

breaking API big time twice is better than breaking it once?

>
>>> 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 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.
>>
>
> 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.

heh, and you think that after this date nobody will use 5.3 and ext devs 
will just say - "uprgade or don't use my functionality". Let's see. 
Mongo tries to get more customers, which means that 5.3 will be 
important for them, even after EOL, because 5.3 has already worked in 
the environment of the customer and the single change is just Mongo added.

>>
>>>> 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.
>>
>
> 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.

maybe because Windows is broken in that regard and the fix that comes is 
about fixing Windows but invoicing all OSes.

>
> 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.
>
Because only a few applications need real 64 bit. Databases are one example.

Andrey