SetSerializeMode(mode)

Hollywood's legacy serializer, which serializes to a proprietary format, only supports #SERIALIZEMODE_HOLLYWOOD. Hollywood's JSON serializer supports all three serialization modes. Here is how the JSON serializer interprets the different serialization modes:

#SERIALIZEMODE_HOLLYWOOD:

This is the default serialization mode. All JSON elements will be serialized to table fields. On top of that, the Hollywood serializer can also serialize binary data and even complete Hollywood functions. Hollywood functions and binary data will be serialized as Base64 data. The Hollywood serializer also supports sparse arrays, i.e. tables whose indices aren't strictly sequential but have gaps between the individual indices. A disadvantage of the Hollywood serializer is that it sometimes uses some special markers in the JSON file to tell Hollywood about the data stored in a JSON element, e.g. whether the data is to be interpreted as a string, as binary data or as a Hollywood function. Consequently, you might not be able to deserialize any arbitrary JSON file with the Hollywood serializer because some things in the JSON might be wrongly interpreted as one of Hollywood's special markers. As long as you only deserialize data written by the Hollywood serializer, you will of course never run into any problems. For example, consider the following table:

t = {foo = "bar", seqarray = {1,2,3,4,5}, sparsearray = {1,[2]=2,[4]=3,[6]=4,[8]=5}}

When serializing this to JSON using the Hollywood serializer, the result will look like this:

{ "seqarray": [1,2,3,4,5], "sparsearray": {"0": 1, "2": 2, "4": 3, "6": 4, "8": 5}, "foo": "bar" }

You can see that sparse arrays are serialized by using named JSON indices. This, on the other hand, means that when deserializing JSON files using the Hollywood serializer named elements that consist of nothing but numbers are interpreted as sparse array fields which is why the Hollywood serializer can't be used to deserialize any arbitrary JSON file but should only be used with JSONs that the Hollywood serializer created.

Another disadvantage of the Hollywood serializer is that the position of elements in the JSON file can be completely random because they are serialized from Hollywood table fields which don't have any particular order. If you want the JSON elements to keep a fixed order, you'll have to use #SERIALIZEMODE_LIST instead.

By default, #SERIALIZEMODE_HOLLYWOOD will convert all JSON key names to lower-case. If you don't want that, you can change the behaviour by setting the NoLowerCase tag to True in SetSerializeOptions(). See SetSerializeOptions for details.

#SERIALIZEMODE_NAMED:

This is like #SERIALIZEMODE_HOLLYWOOD except that it doesn't support any Hollywood extensions. This means that you can only serialize numbers, strings, and tables but no binary data or Hollywood functions. Also, this serializer imposes some restrictions on tables, namely that they must either use string indices or numeric indices but not both. If numeric indices are used, those indices must also be strictly sequential, i.e. table indices must be sequential within a certain range [0..n]. There must not be any gaps like in the example above so it's not possible to serialize sparse arrays with the named serializer. The advantage of #SERIALIZEMODE_NAMED over #SERIALIZEMODE_HOLLYWOOD is that since the named serializer doesn't support any Hollywood extensions you can use it to deserialize any arbitrary JSON file without issues. This is because the named serializers doesn't use any markers because it doesn't support any Hollywood extensions so there is no risk of clashes between JSON data and Hollywood markers. Just like #SERIALIZEMODE_HOLLYWOOD, however, the position of elements in the JSON file can be completely random because they are serialized from Hollywood table fields which don't have any particular order. If you want the JSON elements to keep a fixed order, you'll have to use #SERIALIZEMODE_LIST instead.

By default, #SERIALIZEMODE_NAMED will convert all JSON key names to lower-case. If you don't want that, you can change the behaviour by setting the NoLowerCase tag to True in SetSerializeOptions(). See SetSerializeOptions for details.

#SERIALIZEMODE_LIST:

This mode will serialize JSON elements using lists instead of named table fields. This has the advantage that the order of all JSON elements will be preserved. Also, the spelling of the individual JSON keys will be preserved and you could even use the same key several times. A disadvantage is that it's a bit more difficult to access the JSON data because it is stored in key-value pair tables. For example, consider the following JSON data:

{ "firstName": "John", "lastName": "Smith", "isAlive": true, "age": 27, "address": { "streetAddress": "21 2nd Street", "city": "New York", "state": "NY", "postalCode": "10021-3100" } }

The list serializer will store each key-value in its own table using key and value as named table indices. So to access data from the JSON above, you'd have to use this code:

Print(t[3].key, t[3].value) ; "age 27" Print(t[4].value[2].key, t[4].value[2].value) ; "state NY"

With the named or Hollywood serializer you could access the JSON data by simply using the key name:

Print(t.age) ; prints "27" Print(t.address.state) ; prints "NY"

As you can see, using the named or Hollywood serializer leads to code that is more readable but the downside is that the element order in the JSON won't be preserved so that the JSON might be more difficult to read.

Note that if you use an external serializer (e.g. a plugin) the interpretation of the different serialization modes could be completely different. The documentation above is only valid for Hollywood's inbuilt JSON serializer.

Also note that this function will globally change the serialization mode. You can also change the serialization mode locally by setting the Mode tag in the optional table arguments of functions like SerializeTable(). See SerializeTable for details.

mode

desired serialization mode