Json_decode for an array or object

Question

Locally, I came across a question when someone asked me why I include json_decode output in an array-associated element.

It is easier for me to use helper arrays than stdClasses, and there are already many array_ * functions that support data processing after I decode the json string.

After a short performance test, it turns out that converting to a helper array is about 20% faster than converting to stdClass.

However, the default behavior is $assoc = false . So I wonder if there were any advantages to using stdClasses when working with json data. Are there any json types that cannot be represented in member arrays but in stdClasses?

Answer 1

It may be closed as opinion-based, but for me, I would usually decipher any data structure that is most suitable for use.

For example, let's say JSON described one element as a book, and looked something like this:

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

For me, this is an object, since it is a separate element with different properties. I most likely want to consider it as an object in my subsequent code, so I would decipher it as an object.

Now, if JSON contains data that can be represented by a dictionary, map, hash table, etc., a kind of structure where all key-value pairs were, in fact, similar elements, just with different searches and associated values, I could would consider decoding into an associative array. Maybe a good example of this would be a country code for a country name map, for example:

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

I could persuade him to decode the associative array, because I do not need an object-oriented representation of this information, since I just use it to search for keywords.

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

However, you will find that a number of JSON encoding / decoding libraries in different languages ​​add support to other structures or data types, usually adding processing behavior around primitive data types, but I would not rely on this if you do not fully understand the structure data that will be transmitted and how they will be encoded / decoded in all applications that can transmit data.

For example, PHP provides support for some primitives, as shown in this json_encode() documentation:

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

Finally, with regard to performance, if you get to the point of application development where the number one problem is optimizing performance for runtime, memory usage, etc., and you have reason to believe that you can achieve relatively significant success by optimizing the logic By deserializing JSON (and the subsequent data access logic), you should end up checking your application with representative data and see what works best for you. I guess this will be in line with micro-optimization for most applications.

Answer 2

I think the reason is that JSON is a "JavaScript Object Notation", and therefore people expect an object. If you look at json.org , an object defined as an unordered set of name / value pairs and an array for ordered sets of values, just like the people used in javascript. This can also be found in RFC 4627 :

The terms "object" and "array" come from JavaScript conventions.