RFC: std.json sucessor

[via Digitalmars-d]

On Friday, 22 August 2014 at 16:48:44 UTC, Sönke Ludwig wrote:
> Am 22.08.2014 18:15, schrieb "Marc Schütz" <schuetzm at gmx.net>":
>> Some thoughts about the API:
>>
>> 1) Instead of `parseJSONValue` and `lexJSON`, how about static 
>> methods
>> `JSON.parse` and `JSON.lex`, or even a module level functions
>> `std.data.json.parse` etc.? The "JSON" part of the name is 
>> redundant.
>
> For those functions it may be acceptable, although I really 
> dislike that style, because it makes the code harder to read 
> (what exactly does this parse?) and the functions are rarely 
> used, so that that typing that additional "JSON" should be no 
> issue at all. On the other hand, if you always type "JSON.lex" 
> it's more to type than just "lexJSON".

I'm not really concerned about the amount of typing, it just 
seemed a bit odd to have the redundant JSON in there, as we have 
module names for namespacing. Your argument about readability is 
true nevertheless. But...

>
> But for "[JSON]Value" it gets ugly really quick, because 
> "Value"s are such a common thing and quickly occur in multiple 
> kinds in the same source file.
>
>>
>> 2) Also, `parseJSONValue` and `parseJSONStream` probably don't 
>> need to
>> have different names. They can be distinguished by their 
>> parameter types.
>
> 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).