RFC: std.json sucessor

Sönke Ludwig via Digitalmars-d digitalmars-d at puremagic.com
Fri Aug 22 10:35:19 PDT 2014


Am 22.08.2014 19:24, schrieb "Marc Schütz" <schuetzm at gmx.net>":
> On Friday, 22 August 2014 at 16:48:44 UTC, Sönke Ludwig wrote:
>>
>> Actually they take exactly the same parameters and just differ in
>> their return value. It would be more descriptive to name them
>> parseAsJSONValue and parseAsJSONStream - or maybe parseJSONAsValue or
>> parseJSONToValue? The current naming is somewhat modeled after
>> std.conv's "to!T" and "parse!T".
>
> ... why not use exactly the same convention then? => `parse!JSONValue`
>
> Would be nice to have a "pluggable" API where you just need to specify
> the type in a factory method to choose the input format. Then there
> could be `parse!BSON`, `parse!YAML`, with the same style as
> `parse!(int[])`.
>
> I know this sound a bit like bike-shedding, but the API shouldn't stand
> by itself, but fit into the "big picture", especially as there will
> probably be other parsers (you already named the module std._data_.json).

That would be nice, but then it should also work together with std.conv, 
which basically is exactly this pluggable API. Just like this it would 
result in an ambiguity error if both std.data.json and std.conv are 
imported at the same time.

Is there a way to make std.conv work properly with JSONValue? I guess 
the only theoretical way would be to put something in JSONValue, but 
that would result in a slightly ugly cyclic dependency between parser.d 
and value.d.


More information about the Digitalmars-d mailing list