I disagree with point A. The old behavior makes a LOT more sense symbolically.

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 don't agree with your analogy. The question is more similar to "Can you please tell me the number format of <silence>".

How can the answer to an unfinished question be "0"? 0 is an actual valid answer, when people are asking for number_format(0, 0).

In this case, NULL is definitely more appropriate, because the input is invalid.

> he question is more similar to "Can you please tell me the number format of <silence>".

Well in PHP, the number for <silence> is 0, so it would stand to reason that the formatted number for <silence> is 0 as well.

Of course, in a more sane language, it would throw an exception, rather than silently returning a wrong value.

What's the numeric representation of the volume of <silence>? 0 dB

Since dB are a log scale, more properly, it would be -Inf dB.

0 dB = atmospheric pressure. -Inf dB = vacuum of space.

So you make up a different question to fit the answer you want? Actually that seems about right for PHP.

I think you missed the point here. Steve's analogy asks for a number format, not a volume...

Downvoted for cleverness.

I agree with Steve. "No apples" actually is "0 apples".

Your analogy is a misunderstanding of null. Null is like you asking me how many apples Joe has. I say I don't know. If you write down 0, I'm going to stop you and say, "I didn't say zero, I said I don't know."

BOTH behaviors don't make sense. The right behavior is to throw an exception.

Absolutely agree, and that's PHP's biggest issue. It is constantly doing things like this instead of simply complaining and stopping things down like any sane system would.

If I were in charge of PHP, release 6 would be 5.4.4 with the standard library happily throwing exceptions on invalid input. That's it. The language would be 100% more useful instantly.

As mentioned to parent: then you'd have a lot of work to do to clean up one even more widely used language : )

You mean JavaScript, right? Reading this conversation I was wondering how no comment would point at the same or bigger similar issues in JavaScript.

This depends on language. Or you'd have to dismiss at least on widely used systems programming language as well. : )

Well...if we are allowed to change language completely we could change to a type safe language (as most systems programming are) and we wouldn't have this discussion in the first place since it would be impossible to call the function with a string parameter...

I tell you that you have "foo" apples. Write the number of apples you have on a piece of paper. What did you write?

I tell you you have 12/0 apples. Write the number of apples you have on a piece of paper. Some "functions" are not defined for all inputs. Better to give a "that doesn't make sense" answer than a bogus answer.

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.

Maybe there are other guidelines (Security related, no maintenance for the old release) that were 'forcing' them to update.

I guarantee that security guidelines were not involved in any decision about which version of PHP to use in a project. All PHP code is security tainted and needs protection at the underlying data service layer.

I would almost guarantee security guidelines were the reason. He states they are dealing with tax data, and I would bet they handle some credit card data as well. If they even touch credit card data they have to be PCI compliant (http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu...) which requires specific versions of PHP.

If it requires specific versions of PHP, I would hope that doesn't include a self-patched build that deliberately masks erroneous input data by treating NULL as 0

The moment you run a patched build, you're IMHO not running the officially sanctioned version any more.

Reporter posted this: "...which is why we are moving to a supported, fairly-recent platform". I'm guessing it's the support their after.

I disagree with (A).

According to the php docs

floatval('122.34343The') == 122.34343

floatval('BLARTLBARTFAST') == 0

Why should it take the input and choose a different response than what floatval would respond with?

If floatval returns null on 'BLARTLBARTFAST' and '122.34343The' then this function should return null. If floatval returns 0 (or whatever) than this function should return the same.

It's inconsistent behavior.

> I disagree with (A).

Since you quite clearly have no idea what function we're even talking about or what it's supposed to do, I will just point you to the documentation rather than more explicitly explain on how many levels you are wrong: http://www.php.net/manual/en/function.number-format.php

Pointing to the documentation does not work in this case. The documentation shows the user was not sticking to the function specs, yes, but neither does PHP most of the time. If PHP were a consistent (serious) language, I might see your point. It's not: it generally aims for leniency and minimum (well, small) surprise but doesn't seem to be doing it this time. I think you should make your argument clear.