Hacker News new | past | comments | ask | show | jobs | submit login

With regards to consistency, aside from the fact that I don't think its easy or necessary to compare how functions deal with arguments to how syntax operators etc. deal with values, the situation prior to this change was that there was no consistency even within core functions themselves, before you even start to consider the rest of the language. This could have been resolved by changing all the other functions rather than these few, but that would have messed up a lot more userland code than this change did. I think it was the most pragmatic way of dealing with the issue.

With regards to the documentation, I'll concede that it could have been better. The previous behaviour was undefined and completely undocumented, so I think there are lessons for both "sides", 1) for the PHP team : fully document all changes, even to previously undefined/undocumented cases 2) for the users : don't implement functions in ways that are not documented (and/or santize input/validate output from functions used in such ways).

Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.




> This could have been resolved by changing all the other functions rather than these few

What "these few"? As far as I know there is no list of the functions impacted by the change, how do you define that there's just a few versus not just a few of others?

> but that would have messed up a lot more userland code than this change did.

Because ponies? Where does that arbitrary and unsupported assertion come from exactly?

> I think it was the most pragmatic way of dealing with the issue.

Why? And why was it an issue in the first place?

> The previous behaviour was undefined and completely undocumented

The previous behavior was implementation-defined (as pretty much all of PHP is) and had been stable for a decade. And as I noted above, it was also coherent with userland behavior of PHP when dealing with strings in numerical contexts.

> Also I don't think its strictly correct to say that strings "are compatible" with floats in PHP, rather that in most (but not all) cases strings will be treated/parsed down as floats.

Which, for all intents and purposes, mean they're compatible with floats in most numeric contexts.


From the bug thread that this story refers to, Rasmus states "Most of PHP was using this already, but there were still some stragglers like number_format()". I think my arguments regarding impact of the change are a reasonable extrapolation from that.

Why was it pragmatic? Why was it an issue? There was inconsistency in the ways that functions handled parsing, and many people didn't want that feeling it made it harder to code correctly/consistently, thus it was an issue (part of the greater issue of inconsistency across a number of aspects of PHP). For others it wasn't an issue, which is why a pragmatic solution is the best that could be hoped for, not everyone would agree/like the outcome whatever was done (or not done). I can't see any other way of taking the language forward whilst causing minimum impact to users, which is why I (not you) think it was the most pragmatic way.

Every piece of code we write is "implementation-defined", including the bugs. It wasn't coherent with most other function implementations. Users couldn't reliably treat functions in the same way. I agree it wasn't coherent with numerical operations, but to get that consistency you would have to change a whole load more functions, and you would get many more complaints like this one.

"For all intents and purposes" - I think this discussion (and the many others that have featured on HN talking about similar issues of the weakly typed nature of PHP, such as == vs === ) show that it there are real world consequences to treating strings and numbers as compatible.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: