On Thu, 24 Jul 2014 14:30:08 GMT, Pavel wrote:

Thanks Etienne Cimon.

Let me think about it thoroughly. Here're some questions to think about:

1) Why don't just use null instead of Json.undefined? What are implications of such an approach? Why Json.undefined was introduced?

undefined is specifically there to be able to distinguish between a value that is null and a non-existent value. As such, undefined fields in JSON arrays are either omitted (in case of a dictionary), or replaced with null (in case of a linear array) when converting the Json struct to a JSON string.

2) get and to. It seems like the method of retrieving a value by its name with the default fallback value is missing, for example:

string name = obj.name.get!string("anonymous");

This would be obj.name.opt!string("anonymous"). The get name here is modeled after Variant.get and not after the get method of associative arrays.

3) Just a note, I suppose the doc should advice to use:

obj["key"] notation in first place.

Think of working with JSON string: { "type": "employee", "name": "Mike" }. After parsing you will not be able to fetch "type" value using dot notation, as there is already type member sitting in any vibe.data.Json object.

There is actually an open ticket that requests to remove Json.opDispatch altogether. Based on my personal view I'd agree, but I know that there are also some people who strongly favor the dot based syntax, so I'm reluctant to actually remove it.

4) Why do we need vibe.data.Json structure level at all?

Alternative to the Json structure is Variant[string]. For arrays one may use Variant[]. And provide some functions like "readJson", "writeJson", and maybe some other variations.

Because Variant is too lax in what it can take. The Json struct statically makes sure that only the supported types can be stored. It would be possible to use an Algebraic!(bool, int, float, ...) (not sure if it would accept typeof(null), though), but it's often also very useful to be able to refer to the contained types using an enum instead of a type info pointer, for example to be able to use final switch, or using the type as efficient AA keys or indices.

What I'm actually planning to do though, is to implement a generic FixedVariant type that basically is a fully generic tagged union. This can then be used as alias Json = FixedVariant!(JsonType, bool, int, ...) and has some advantages, such as supporting conversion to other similar FixedVariant types like the corresponding Bson definition.