One wonders, how would it be possible for this gentleman to work under the onus of such a horrifically restrictive enterprise-y change control board and yet have the ability to upgrade the toolset for 50 or 60 seperate products, his words, without going through said onerous change control process? It seems like there is a giant gaping hole in this company's processes, not surprising as it sounds like a horrible place for anyone with talent to work.
PHP Bug: #50696: number_format when passed a 0, returns null
41–50 of 51 posts
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#42Although Rasmus is quite clearly right to have fixed the undefined behaviour and is probably quite charming in person, if anyone in our company responded to one of our customers like that, well, there'd be trouble. He could've saved himself a lot of grief if his first reply had been: Hi, I'm sorry to hear this change has broken your existing code. We've been cleaning up undefined behaviours such as the one you're rel…
he could also tested his damn application before upgrading php.
in his make up world that makes it too dificult to fix his code, he would have to go trhu 7 levels of testing hell... so why not apply it to the platform?
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#43Earlier quoted context omitted.
+1. It should thrown an exception and abort the script with an ugly error traceback. If the documentation says "float" and you can hand it a numerical string, then either the function or its documentation have a bug that needs correcting.
I wouldn't go as far as throwing an exception. A notice maybe.
Asking a function that formats a number and that is defined that way in the documentation to format a string is a programming mistake. As the discussion clearly states, it's a minor change in application code that would make it both clearer and more robust.
I would go as far as recommend using a USB shock device to issue a warning to the programmer every times a mistake like this is made. ;-)
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#44Although Rasmus is quite clearly right to have fixed the undefined behaviour and is probably quite charming in person, if anyone in our company responded to one of our customers like that, well, there'd be trouble. He could've saved himself a lot of grief if his first reply had been: Hi, I'm sorry to hear this change has broken your existing code. We've been cleaning up undefined behaviours such as the one you're rel…
Presumably the people in your company aren't unpaid volunteers .
> From September 2002 to November 6th 2009, he had been employed by Yahoo! Inc. as an Infrastructure Architecture Engineer.
Some might say "PHP developer"
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#45"Escalate? Oh how I wish I had someone to escalate to." Classic.
he sure does wish that :
"I'm not a real programmer. I throw together things until it works then I move on. "
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#46Earlier quoted context omitted.
You know what's more depressing? This clueless guy is one of the (wild guess) 5% of PHP users who can file a bug report and follow it...
I would guess even lower. I'm not sure why that depresses you though. In my mind, that's actually a sign of success for the language.
I wouldn't guess. why guess? why not just not quote a number at all since you have no idea?
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#47Earlier quoted context omitted.
Presumably the people in your company aren't unpaid volunteers .
> From September 2002 to November 6th 2009, he had been employed by Yahoo! Inc. as an Infrastructure Architecture Engineer. Some might say "PHP developer"
They might indeed, but the person filing the bug report in question (in their capacity as a user of PHP, at any rate) is not a customer of Yahoo! Inc., and thus Rasmus' employment there is irrelevant to the point at hand.
That point, rhetoric aside, is that the reporter is not party to a commercial contract with the people who fix bugs in PHP, whoever they might happen to be. Consequently, there should not be the "trouble" that moconnor asserted would occur should anyone in his organisation respond to a customer in that manner. The two parties simply do not have that relationship.
The phrase "unpaid volunteer" comes from Rasmus himself, in the bug report under discussion: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure."
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#48I'm definitely on the PHP guys with this. A big criticism against PHP is that it's inconsistent in numerous ways. This bugfix is obviously part of an effort to standardize function behaviour. Go PHP!
But the problem with this is that those inconstancies have been around for so long that people have come to rely on them. So when you try to "fix the glitch", people get upset. So, when you say it's part of an effort to standardize behavior, I think you're right. But is this the right way to go? I mean, was the old behavior that bad? Why not just flag it as a warning and mark it as deprecated functionality? Then wait…
I do not agree, if the programmer relies on idiosyncrasies of a system then it's the programmer's fault, no matter how long these idiosyncrasies were in the system. It's the programmers job to anticipate on that. It is also a fallacy to think (especially for a programmer) that your program is done when finished, last 40 years have shown that a programmer always has to do maintenance just like buildings and bridges and other infra.
Further I agree with what Rasmus states as one of his last remarks in that bug thread: "Wow, a classic case of how not to treat unpaid volunteers who provide critical pieces of your money-making infrastructure."
In other words, go make yourself a programming language if you have a big mouth towards volunteers when you scheme of making money with their system fails you, the bloody arrogance.
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#49Interesting 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..
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…
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.
Re: PHP Bug: #50696: number_format when passed a 0, returns null
#50Earlier quoted context omitted.
Equality isn't transitive in PHP :/. Of course, IMO, the real coding horror here is that in an error circumstance no exception is raised.
This. There are dozens of situations where, given instructions that simply don't make sense, PHP arbitrarily picks some half-baked behavior instead of giving an error. So much so that I think the original poster is out of line for even considering tax planning in a language that wants to guess what you might have wanted to happen!
+1