PHPC-2350: Implement JSON methods for PackedArray

[alcaeus]

PHPC-2350

We can leverage bson_new_from_json to create a bson_t for an array, and bson_as_json_with_opts lets us export the bson_t to JSON with an array being the root object.

Note that since bson_new_from_json was intended to read documents, the resulting PackedArray instance will retain the original keys in the object, but iterating it or converting it to JSON will reindex the array. However, when using the PackedArray instance in certain ways will cause errors (see bson-packedarray-fromJSON-003.phpt which fails the last operation). The only option I see is to iterate the resulting bson_t and either re-index it (essentially re-writing a bson_t array) or to throw if one of the keys isn't what we expect. Since we have the mantra of "be lenient in what you accept, but strict in what you produce" I'm inclined to go with the first option, despite this potentially causing some overhead. WDYT @jmikola?

[jmikola]

Note that since bson_new_from_json was intended to read documents, the resulting PackedArray instance will retain the original keys in the object, but iterating it or converting it to JSON will reindex the array. However, when using the PackedArray instance in certain ways will cause errors.

I'm having trouble understanding why this fails but the preceding $bson->toCanonicalExtendedJSON() does not.

Does bson_json_opts_set_outermost_array() apply some logic that disregards invalid keys, while the code path for converting a nested array to extended JSON does not?

The only option I see is to iterate the resulting bson_t and either re-index it (essentially re-writing a bson_t array) or to throw if one of the keys isn't what we expect. Since we have the mantra of "be lenient in what you accept, but strict in what you produce" I'm inclined to go with the first option, despite this potentially causing some overhead.

If PackedArray::fromPHP() requires a well-formed list (see: bson-packedarray-fromPHP_error-001.phpt), I don't see why we can't require that in fromJSON() as well.

Perhaps we can't prevent libbson from accepting a JSON object with sequential numeric string keys starting at zero, but if it's easy to detect something like { "foo": "bar" } I'm all for throwing an error there.

[alcaeus]

I added logic to iterate the array and compare the keys. I've used strtoll to parse the string, as I didn't want to allocate memory to convert the expected key to a string. I'm not sure if that has any performance implications, but I don't expect this method to be somewhere in the hot path given its limited usefulness.

[jmikola]

Recapping our Slack discussion, we discussed a caveat with strtoll() accepting non-canonical numeric strings. I'll review the second approach.