json_encode(): added option to turn only empty arrays into object

[datibbaw]

This PR supersedes #454 in the sense that I've fixed up my repo :)

I ran into a situation whereby empty php arrays should be sent as objects but are serialized into JSON as an Array type, i.e. [].

The JSON_FORCE_OBJECT option will solve that, but that also affects numerically indexed arrays; in my case, I wanted a bit of both, so I'm proposing JSON_FORCE_EMPTY_OBJECT that will serialize only empty arrays as objects, but filled arrays will be serialized according to their keys or other flags.

A specific use-case is when the encoded value is passed to JavaScript; if an array is passed, you can add properties to it, but when you later do JSON.stringify() it returns an empty array. This is quite unlike PHP of course, because arrays can be both things, depending on whether it contains only numeric keys or not.

I readily admit that this use-case is fairly uncommon :)

[lstrojny]

(y)

[lstrojny]

That’s what I was trying to say 👍

[DaveRandom]

I've already made these comments elsewhere but for the record: I'm quite seriously in two mind about this, tending towards the "no" option, but my reasons for that are probably not totally in line with the PHP "mission" (such as one exists).

This kind of thing makes it easier to be write lazy code and have the engine magically work out what you wanted but really there comes a point when you need to be explicit, otherwise you end up writing code that is very opaque. In this particular case, you may end up being bitten by an array that unexpectedly becomes an object at the other end because it happens to have no elements in it. However, this view amounts to forcing stylistic preferences on the user.

A better solution would be to implement an O(1) mechanism to determine where an array is indexed or associative so it can be handled accordingly, along with mechanisms exposed to userland to specify that something is one or the other regardless of what it contains - really the only thing that's required is a array_assoc() or whatever since array_values() can already be used to ensure that something is indexed.

The real solution to the underlying problem is of course object literals, but that's a can of worms I won't open here.

To summarise, IMO this is the wrong way to solve the problem. But since the better solutions are unlikely to pass muster with internals, it will probably have to do.

[ParkFramework]

Is very needed option!

[php-pulls]

Comment on behalf of krakjoe at php.net:

Since this PR has merge conflicts, requires an RFC and discussion, and since the author seems to have abandoned the idea, I'm closing this PR.

Please take this action as encouragement to start an internals discussion (with RFC), open a clean PR, and move forward with the feature.