Am 23.08.2014 04:23, schrieb deadalnix:
First thank you for your work. std.json is horrible to use right now, so
a replacement is more than welcome.
I haven't played with your code yet, so I may be asking for somethign
that already exists, but did you had a look to jsvar by Adam ?
You can find it here:
https://github.com/adamdruppe/arsd/blob/master/jsvar.d
One of the big pain when one work with format like JSON is that you go
from the untyped world to the typed world (the same problem occurs with
XML and various config format as well).
I think Adam got the right balance in jsvar. It behave closely enough to
javascript so it is convenient to manipulate, while removing the most
dangerous behavior (concatenation is still done using ~and not + as in JS).
If that is not already the case, I'd love that the element I get out of
my JSON behave that way. If you can do that, you have a user.
Setting the issue of opDispatch aside, one of the goals was to use
Algebraic to store values. It is probably not completely as flexible as
jsvar, but still transparently enables a lot of operations (with those
pull requests merged at least). But it has another big advantage, which
is that we can later define other types based on Algebraic, such as
BSONValue, and those can be transparently runtime converted between each
other in a generic way. A special case type on the other hand produces
nasty dependencies between the formats.
Main issues of using opDispatch:
- Prone to bugs where a normal field/method of the JSONValue struct is
accessed instead of a JSON field
- On top of that the var.field syntax gives the wrong impression that
you are working with static typing, while var["field"] makes it clear
that runtime indexing is going on
- Every interface change of JSONValue would be a silent breaking
change, because the whole string domain is used up for opDispatch
