We will try to stop fixing bugs in PHP
bugs.php.net
We will try to stop fixing bugs in PHP
1–10 of 319 posts
Re: We will try to stop fixing bugs in PHP
#2Upvoting, because the issue at hand is so old that I find it funny people will use this as a reason as to why "PHP sucks".
For the record, the version in question was 5.3.1 vs 5.1.6, two releases away and three years apart. Of course you'll need to test updates to your app with such version changes. Yes, using semver means this is a minor version release, but if we do that, I'll be first to note the lovely hash syntax changes in Ruby 1.9.
In any case, the current release is 5.4.4.
Re: We will try to stop fixing bugs in PHP
#3I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold).
It returned 0 previously for "", why change it now? Was "" == 0 a bug ?
Re: We will try to stop fixing bugs in PHP
#4Upvoting, because the issue at hand is so old that I find it funny people will use this as a reason as to why "PHP sucks". For the record, the version in question was 5.3.1 vs 5.1.6, two releases away and three years apart. Of course you'll need to test updates to your app with such version changes. Yes, using semver means this is a minor version release, but if we do that, I'll be first to note the lovely hash synta…
Sorry I couldn't grok what your opinion on semver was.
Ruby 1.9 introduced new hash syntax but did NOT break the existing syntax one so it was a minor version release (backwards compatible).
PHP made an backwards incompatible change in their code so it should have been a major version increase.
So as far as I can see Ruby is in the right and PHP is in the wrong with regards to adhering to semver.
Is that not your opinion?
Re: We will try to stop fixing bugs in PHP
#5Upvoting, because the issue at hand is so old that I find it funny people will use this as a reason as to why "PHP sucks". For the record, the version in question was 5.3.1 vs 5.1.6, two releases away and three years apart. Of course you'll need to test updates to your app with such version changes. Yes, using semver means this is a minor version release, but if we do that, I'll be first to note the lovely hash synta…
Sorry I couldn't grok what your opinion on semver was. Ruby 1.9 introduced new hash syntax but did NOT break the existing syntax one so it was a minor version release (backwards compatible). PHP made an backwards incompatible change in their code so it should have been a major version increase. So as far as I can see Ruby is in the right and PHP is in the wrong with regards to adhering to semver. Is that not your opi…
[deleted]
Re: We will try to stop fixing bugs in PHP
#6To standardize PHP code is good, let's be clear... There's a lot of "misbehaves" in PHP. And if you're not casting or checking all the time you can get a wrong result, without even knowing. At least now/then (it's an old topic) number_format WILL tell you that you're not formatting a number and that's GOOD.
Re: We will try to stop fixing bugs in PHP
#7I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold). It returned 0 previously for "", why change it now? Was "" == 0 a bug ?
A) The new behaviour makes more sense.
B) The change was discovered as a difference in behaviour in two major releases that were three years apart.
C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful.
D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix.
E) You don't pass a string into a function that's usually returning a string without at least casting to a string when part of its intended behaviour is at times not returning a string. Casting in this case even before the function even changed would have been an exceedingly good idea.
F) (edit) I vote we burn in hell PHP developers who tack on comments to a long closed bug report to offer their opinions like joezimjs did. Especially when they display a basic ignorance in saying crap like "NULL is neither a string nor a number."
Re: We will try to stop fixing bugs in PHP
#8I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold). It returned 0 previously for "", why change it now? Was "" == 0 a bug ?
A) The new behaviour makes more sense. B) The change was discovered as a difference in behaviour in two major releases that were three years apart. C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful. D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix. E) You don't pass…
I work on systems where D) is perfectly reasonable. Where one "small" change results in a hell of a lot of regression testing and doc changes.
What I don't get is that they are keen to modify php source. But not to just keep using the same php release?
I agree with E, they take floats not strings apparently.
Re: We will try to stop fixing bugs in PHP
#9I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold). It returned 0 previously for "", why change it now? Was "" == 0 a bug ?
A) The new behaviour makes more sense. B) The change was discovered as a difference in behaviour in two major releases that were three years apart. C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful. D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix. E) You don't pass…
[deleted]
Re: We will try to stop fixing bugs in PHP
#10Earlier quoted context omitted.
A) The new behaviour makes more sense. B) The change was discovered as a difference in behaviour in two major releases that were three years apart. C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful. D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix. E) You don't pass…
I work on systems where D) is perfectly reasonable. Where one "small" change results in a hell of a lot of regression testing and doc changes. What I don't get is that they are keen to modify php source. But not to just keep using the same php release? I agree with E, they take floats not strings apparently.
Maybe there are other guidelines (Security related, no maintenance for the old release) that were 'forcing' them to update.