On 31.01.2014 13:30, Arvids Godjuks wrote:
2014-01-31 Derick Rethans <
[email protected]>:
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:
RFC.
Okay, so I've just looked at your attempt to port the MongoDB driver to
the "size_t" branch:
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.
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.
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