RFC: std.json sucessor

[Sönke Ludwig via Digitalmars-d]

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