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.
