json_decode to array or to object

Question

Latly I came upon a question where someone asked me, why I turn the output of json_decode into an assoc array.

For me it's easier to use assoc arrays than stdClasses and there are already many array_* functions which support data handling after I decode the json string.

After a short performance test it turns out, that the conversion to an assoc array is about 20% faster than the conversion to stdClass.

Nevertheless, the default behavior is $assoc = false. So I wonder, were are the benefits of using stdClasses when dealing with json data. Are there any json types which can't be represented in assoc arrays, but in stdClasses?

Answer 1

This might get closed as opinion based, but for me, I would typically decode to whatever data structure makes the most sense for the use case.

For example, say the JSON described a single item like a book and looked something like this:

{
    "title": "Cool Book",
    "author": "Amazing Author",
    "publisher": "Evil Corporation",
    ...
}

To me that is an object, in that it is a single item with different properties. I would be likely to want to treat it like an object in my subsequent code, so I would decode it as an object.

Now if the JSON contained the sort of data that may represent a dictionary, map, hash table, etc. sort of structure, where all the key-value pairs were, in essence, similar items, just with different lookups and mapped values, I might consider decoding to an associative array. Maybe a good example of that would be a country code to country name map like this:

{
    "AF": "Afghanistan",
    "AX": "Aland Islands",
    "AL": "Albania",
    "DZ": "Algeria",
    ...
}

I might be inclined to decode this to an associative array, because I don't need any object-oriented representation of this information, since I am just using this for key-value lookups.

To answer your question about other data structures that can be represented in JSON, officially there are only two data structures supported in JSON - objects and numerically-indexed arrays. This is because of the javascript-based roots of the serialization format, where, for example, the concept of an "out-of-the-box" associative array doesn't exist.

You will however find that a number of JSON encoding/decoding libraries across languages do add support for other data structures or types, typically adding handling behavior around primitive data types, but I would not rely on this unless you fully understand the data structures that are going to be passed and how they are going to be encoded/decoded across all applications that might pass the data around.

For example, PHP provides support for certain primitives as shown in this note from the json_encode() documentation:

Note: Like the reference JSON encoder, json_encode() will generate JSON that is a simple value (that is, neither an object nor an array) if given a string, integer, float or boolean as an input value. While most decoders will accept these values as valid JSON, some may not, as the specification is ambiguous on this point. To summarise, always test that your JSON decoder can handle the output you generate from json_encode().

Finally, with regards to performance, if you get to the point in your application development where the number one concern is optimizing performance for execution time, memory utilization, etc. and you have reason to believe that relatively substantial gains can be made by optimizing the JSON deserialization (and subsequent data access) logic, then you should ultimately test your application with representative data and see what works best for you. My guess is that this would be along the lines of a micro-optimization for most applications.