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?

The null type is already reserved for pointers, and there's no way to overload operations on a null type with a Json object.

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");

True, that's why there's an opCast for this though so you can also do string name = obj.name to achieve the same result, but I prefer the more verbose way (personally).

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.
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.

I think it's true that there are flaws with having a .type property, which collides with opDispatch, the workaround is more likely going to be using opIndex by doing json["type"], although this is a very minor workaround compared to the level of verbosity that would be needed to make Variant[string] work with Json deserialized objects ... how would you check for a null type in a variant for example?