11–20 of 319 posts
To 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.
I 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 ?
The function requires a float, and the developer is passing in an empty string. To rely on this type of edge-case behavior is ridiculous, in my opinion.
To 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.
If PHP has any place in the world at all, it's as a language for the web with a minimum of extraneous boilerplate. If it fails at that goal, well, wtf? If you're going to be all proper about things, why not just do it in Python or some other sane language?
Earlier 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.
I 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 tell you that you have no apples. Write the number of apples you have on a piece of paper. What did you write? I bet it was 0, not some arbitrary, non-writable symbol for an abstract concept that could mean "nothing" or "error" or "empty" or ..
I 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 ?
[1] http://php.net/number-format says the first argument expects float, and does not say what happens if it receives non-floats.
EDIT: Rasmus calls the bug reporter an idiot in the first reply. It's probably some sysadmin that has been tasked with upgrading the infrastructure and really has no idea what to do. So rude. It would take just as long to write: "Sorry about the inconvenience. We changed this undefined behavior for consistency's sake. You could cast the first argument to a float like: '[sample code]' and you'll get the old behavior back. One of our consulting partners [link] could help you with that if you'd like." Instead, Rasmus set the tone that he was superior from the onset.
Upvoting, 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…
{"a", "b"}
String class was also given a nice kick in the ass, at least in regards to iteration.
Would you say that these were not backwards incompatible changes? Code that worked before stopped working. Breaks BC in my book. And in both cases the changes were arguably for the better.
- Stop writing code with uninitialized variables - Stop iterating over stuff that shouldn't be iterated over in that way
As far as why the changes were thus, it was decided to destroy PHP 6 - do people still write books about that? - and port every change other than unicode support down to 5.x. Someone feel free to correct me on that point.
That said, I don't see this taking 'months' either, they could just write a wrapper function that mimics the old behaviour and their tests should cover it. If their quality control or inner workflows make changes like this take months, I'd expect that upgrading to a new PHP version and the related testing and QA should take them years.
Upvoting, 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…
In one patchlevel of 1.8.6, they've added a check against creating new Ruby objects while the GC is running (I hope I remember this right), breaking all SWIG extensions at once.
Ruby 1.8.7 changed the C extension API, I think? I'm not sure if 1.8.7 broke the old one or if 1.9 did.
Ruby 1.9 broke "when 5:" in case statements. Files also started needing "# Coding: UTF-8" comments. And then there are subtle changes that probably aren't even documented, like [Math.sin 0] not being valid syntax anymore. Block variable scoping and automatic splitting into Arrays is different.
Ruby 1.9.2 (!) changed the way require() works and added require_relative() which is impossible to properly backport.
And Ruby 1.9.3 fixed a parser bug again, breaking code that worked on 1.9.2. (I think you could have a superfluous "do" in one place.)
Those are the breaking changes that I can remember from first-hand experience now, only the last one is second-hand over IRC. And this is excluding Rake, Rubygems and all the other crap that breaks at every other git commit.
Ruby is a bad example.