Hacker News Reader

Comment by ddbb | Hacker News Reader

Interesting discussion in there, but I think the PHP guys are right on this one. You should never rely on undefined behavior of any API for mission critical code.

Always use what is documented so you don't have to cry later..

View on HN

The PHP guys are right in the same sense a store is right that it doesn't have to take a return without a receipt. But most stores will do so anyway in order to maintain good will. Whenever we come across undocumented or undefined behavior that will change in a new release, we try very hard to not change it unless it's absolutely necessary.

I would argue that it makes a lot more sense for a non-number to return NULL than to return 0. If it returns 0, how do you distinguish between "0" and ""? At least with a NULL return value you can use the function to see if you're even looking at a number at all.

Sure. And I haven't used PHP in about a decade. But it sounds to me like this was overlooked by them and so returned 0 for many years. Despite being undocumented behavior, fixing it causes a breaking change. On my team whenever we come into this situation and realize that fixing overlooked things can actually "break" people, we really think twice about the fix. Even if in theory the fix on its own is totally the right thing to do.

> fixing it causes a breaking change. On my team whenever we come into this situation and realize that fixing overlooked things can actually "break" people, we really think twice about the fix.

Answered in the 2nd comment from Rasmus:

If this was changed in a minor version, I'd agree with you on the BC change, but we have been working on catching these weird edge-case scenarios that lead to unexpected bugs.

i.e. they thought about it and decided this version was an acceptable one for making breaking changes.

I'd take the other side... but I can understand them choosing either way.

My vote for the other side is because php guys didn't document the change. Other pages show exactly what happens in strange cases - like in "If delimiter is an empty string (""), explode() will return FALSE." There's no mention about the change on http://php.net/manual/en/function.number-format.php and they list the result as "string" without any other notes. Making the function backwards compatible wouldn't hurt anyone either, because it would restore the behaviour for people using "" and would change nothing for ones using normal values all the time and ones who started casting to a number because of this change. But yes - it's pretty much php guys' call.

Seems reasonable. And I don't think you guys got the humor when he said "Escalate". You all want to think you're SO smart and nobody else can pick his nose. Obviously he knew who he was talking to, do you really think he uses PHP and doesn't know who he was dealing with?

Anyway, saying they wouldn't fix it is fine, but the bitchy answers he got to legitimate questions just shows how juvenile R is.

When I first read it quickly I thought it sounded a fair complaint, then I saw this comment and figured I should think again. On 2nd read I picked up the subtleties re: undocumented behaviour, reason behind the change & effect reverting it would have and yes, I think I agree after all.

Different 'bug', similar theme: I'd be v. interested to hear what HN folks think about http://bugs.php.net/bug.php?id=47494. I explained the problem here: http://insomanic.me.uk/post/191397106/php-htmlspecialchars-h...

Summary: PHP 5.3 introduces a scenario where:

  display_errors=off, log_errors=on => warning msg is logged (but not displayed, of course..)   
  display_errors=on => NO warning is logged OR displayed(?!)

Took me ages to figure out, that one did..

This would work if programmers actually documented their code.

I remember posting similar sentiments on Reddit about 3 years ago and getting downmodded to oblivion. In hindsight, I think I was wrong and the herd was right. If you restrict yourself to what's documented, you'll miss out on most of the interesting and cutting-edge stuff. And that's what lets you build a cool, differentiated, useful project.

Instead, I think you should budget time and money for crying later. ;-)

Reply on news.ycombinator.com