Hacker News Reader

Comment by mparlane | Hacker News Reader

I am mostly on the side of the bug reporter here. PHP changed the behaviour of a simple method that has been there since PHP4 (which is oooold).

It returned 0 previously for "", why change it now? Was "" == 0 a bug ?

View on HN

A) The new behaviour makes more sense.

B) The change was discovered as a difference in behaviour in two major releases that were three years apart.

C) Rasmus Lerdorf can change PHP however he wants. It is precisely because of this that PHP has been so {'widely success', 'pain'}ful.

D) The reporter was being overly dramatic regarding the change going to take a supposedly crazy amount of time to fix.

E) You don't pass a string into a function that's usually returning a string without at least casting to a string when part of its intended behaviour is at times not returning a string. Casting in this case even before the function even changed would have been an exceedingly good idea.

F) (edit) I vote we burn in hell PHP developers who tack on comments to a long closed bug report to offer their opinions like joezimjs did. Especially when they display a basic ignorance in saying crap like "NULL is neither a string nor a number."

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 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.

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

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

Downvoted for cleverness.

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

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

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

> 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.

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."

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

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 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 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.

I don't believe there should be any obligation for developers to maintain undefined behavior across versions. Even with defined behavior, sometimes APIs change, for legitimate reasons.

The function requires a float, and the developer is passing in an empty string. To rely on this type of edge-case behavior is ridiculous, in my opinion.

Regardless of the prior behavior, that particular behavior was not documented [1] and subject to change. I do think it is PHP's (very big) fault that the proper documentation on various edge cases is missing, but it is a bit too much to disallow PHP to change undocumented behaviors. That said, the proper documentation is not enough (and PHP does not get this right either); it's rather a mere prerequisite.

[1] http://php.net/number-format says the first argument expects float, and does not say what happens if it receives non-floats.

Well, exactly. It doesn't say what happens, so pass floats or expect the unexpected. I get your point but I don't think I have ever seen documentation anywhere that covers all of the possible 'abuse' scenarios.

It is possible to add a catch-all clause to the documentation. For example any non-float argument is converted to float via floatval(), or raises an error, and so on. This behavior can be made consistent across every API so that the documentation has only one place to describe it. PHP is missing this either AFAIK.

I agree this would be ideal. Will definitely keep this in mind when writing documentation (and code) for my own tiny open source projects. All the double and triple checking just adds so much bloat most of the time...

> This behavior can be made consistent across every API so that the documentation has only one place to describe it.

Sounds like that's what 'zend_parse_parameters' does, actually.

Documentation is hard, thats why most of it is open source. Pretty sure you can edit the php docs online if you so chose.

The specific usecase the bug reporter has provided DOES raise a warning, which he has intentionally routed to /dev/null

php -r 'print number_format("",0) . "\n";'

PHP Warning: number_format() expects parameter 1 to be double, string given in Command line code on line 1

Reply on news.ycombinator.com