The case is made quite clear by the JSON Checker and the test suite it provides. The suggestion that one has to suck up to the _right_ group to get PHP’s JSON extension to behave like the JSON Checker is very illuminating.

However the “internals team” is not such a homogeneous bunch as you make it sound. Unfortunately decisions are often not thought through all the way. So if you feel strongly about something try to softly check up the issue with multiple people. It pays to know the internal cliques as well. Not easy to dig through from the outside unfortunately :-/

Anyways usually php.net tries to follow standards. I do not know if there was any reaction so far from anyone with the necessary karma.

One more thing to note: While single developers have the say over their respective pecl packages, this changes once the code goes into core, at which point more people can influence the direction of the code. So without being a JSON expert myself, try to make your case clear and I think you should have a good shot at getting this fixed for 5.2.2. Also please consider phpt’ing your unit tests to prevent such breakage in the future.

I opened a bug related to PHP 5.2.0RC1 and the decoding issue. I then dug deeper into the way JSON should work (according to the JSON Checker test suite), and declared my bug bogus.

Then PHP 5.2.1 came along, and the behavior changed. As I mentioned in the post, and Paul mentioned above, some pre-bug-filing conversations were had about this new behavior, and the internals team made this change intentionally. They do not consider the PHP 5.2.1 behavior to be buggy or broken.

I dont understand that sentence. Didnt you say that it does not return NULL. So why did _you_ bogus your own bug?

/me is confused

It’s a bit ridiculous to only support objects and arrays with a decoder. It would be easy enough to support number, string, boolean and null as well, and then the user of the API make a determination of whether the resultant type is appropriate. Or add a flag to limit filter the result for you (returning an error condition). As an earlier commented noted, the way of the web is: “be liberal in what you accept”.

Of particular importance, it appears, given this blog entry, that json_decode() function returns NULL on errors. That’s pretty bad. Since null is a perfectly valid value in JSON. Even if this API never returns anything but array / object, it’s not immediately obvious, without looking at the doc that this would be the case. Someone might do a quick test and find json_decode(’null’) returns NULL and think - woot! it handles nulls! When of course it doesn’t. This would have been a good case for using an exception in the API. Or returning an error object you could sniff for. Or something. NULL is just bad.

…