Hacker News Reader

Comment by josegonzalez | Hacker News Reader

The following does not work anymore in 1.9 (at least when it was released, who knows if they reverted the change):

    {"a", "b"}

And there were plenty of gems and small scripts online I was able to get working just fine under 1.8.7 but not 1.9. Thankfully that is largely no longer the case, as things have been updated or replaced.

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.

View on HN

It doesn't work in the latest 1.9 either. It was a bizarre syntax that hardly anyone used from my experience (I've been a library-oriented Rubyist for several years and never saw it in production code.)

However, String is a good point, and especially around character encodings. Not to mention threads, major stdlib changes, enumerators, and more..

I don't "really mind" if it breaks totally (i.e. throws an appropriate exception or doesn't parse the syntax check).

I find it much more irritating when the behaviour subtly changes and introduces edge cases that may not be picked up in testing / normal usage.

Passing in an empty string to a function that states it takes float as it's argument is certainly an edge case the developer should have thought of.

The again, in PHP, interpreting strings as floats is not unusual and pretty well defined. So in PHP it's also a case the developer could have considered normal in his expectation that PHP would behave as usual (and it did, prior to 5.3, for this precise function)

Not for user-provided input. That's just a dumb thing to do in any language.

> Not for user-provided input.

Not what for user-provided input? The source of a string does not matter to this rule of PHP: a string used in numeric context will be parsed and converted, if it can not be parsed as a number its numeric value will be 0. That's it. That's how the language defines strings in numeric contexts.

> That's just a dumb thing to do in any language.

Sure, you won't get any argument from me on that, but that remains how PHP works and has always worked.

Probably. But then again, we're talking about a language where THIS happens:

php> echo "2coolforschool" + 1;

php> echo "2.1coolforschool" + 1;

3.1

php> echo "coolforschool" + 1;

So treating all kinds of garbage as valid numbers is absolutely part of PHP.

That's just the general design philosophy of the MP components of the LAMP stack.

Do the stupidest thing that could possibly work; and it probably will. For now.

Reply on news.ycombinator.com