std.data.json formal review

[Sönke Ludwig via Digitalmars-d]

Am 11.08.2015 um 19:30 schrieb deadalnix:
> Ok some actionable items.
>
> 1/ How big is a JSON struct ? What is the biggest element in the union ?
> Is that element really needed ? Recurse.

See 
http://s-ludwig.github.io/std_data_json/stdx/data/json/value/JSONValue.payload.html

The question whether each field is "really" needed obviously depends on 
the application. However, the biggest type is BigInt that, form a quick 
look, contains a dynamic array + a bool field, so it's not as compact as 
it could be, but also not really large. There is also an additional 
Location field that may sometimes be important for good error messages 
and the like and sometimes may be totally unneeded.

However, my goal when implementing this has never been to make the DOM 
representation as efficient as possible. The simple reason is that a DOM 
representation is inherently inefficient when compared to operating on 
the structure using either the pull parser or using a deserializer that 
directly converts into a static D type. IMO these should be advertised 
instead of trying to milk a dead cow (in terms of performance).

> 2/ As far as I can see, the element are discriminated using typeid. An
> enum is preferable as the compiler would know values ahead of time and
> optimize based on this. It also allow use of things like final switch.

Using a tagged union like structure is definitely what I'd like to have, 
too. However, the main goal was to build the DOM type upon a generic 
algebraic type instead of using a home-brew tagged union. The reason is 
that it automatically makes different DOM types with a similar structure 
interoperable (JSON/BSON/TOML/...).

Now Phobos unfortunately only has Algebraic, which not only doesn't have 
a type enum, but is currently also really bad at keeping static type 
information when forwarding function calls or operators. The only 
options were basically to resort to Algebraic for now, but have 
something that works, or to first implement an alternative algebraic 
type and get it accepted into Phobos, which would delay the whole 
process nearly indefinitely.

> 3/ Going from the untyped world to the typed world and provide an API to
> get back to the untyped word is a loser strategy. That sounds true
> intuitively, but also from my experience manipulating JSON in various
> languages. The Nodes produced by this lib need to be "manipulatable" as
> the unstructured values they represent.

It isn't really clear to me what you mean by this. What exactly about 
JSONValue can't be manipulated like the "unstructured values [it] 
represent[s]"?

Or do you perhaps mean the JSON -> deserialize -> manipulate -> 
serialize -> JSON approach? That definitely is not a "loser strategy"*, 
but yes, it is limited to applications where you have a partially fixed 
schema. However, arguably most applications fall into that category.

* OT: My personal observation is that sadly the overall tone in the 
community has generally become a lot less friendly over the last months. 
I'm a bit worried about where this may lead in the long term.