std.data.json formal review

[H. S. Teoh via Digitalmars-d]

On Tue, Jul 28, 2015 at 03:55:22PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/28/2015 3:37 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Tue, Jul 28, 2015 at 03:29:02PM -0700, Walter Bright via Digitalmars-d wrote:
> >Ideally, I'd say hook it up to std.conv.to for maximum flexibility.
> >Then you can just use to() to convert between a JSON container and
> >the value that it represents (assuming the types are compatible).
> 
> Well, I wouldn't want std.conv to be importing std.json.

I'm pretty sure std.conv has interfaces that allow you to keep
JSON-specific stuff in std.json, so that you don't get the JSON
conversion capability until you actually import std.json.


> >OTOH, some people might want the option of parser-driven data
> >processing instead (e.g. the JSON data is very large and we don't
> >want to store the whole thing in memory at once).
> 
> That is a good point.
> 
> 
> >I'm not sure what a good API for that would be, though.
> 
> Probably simply returning an InputRange of JSON values.

But how would you capture the nesting substructures?


> >>To create output:
> >>
> >>     auto r = ast.toChars();  // r is an InputRange of characters
> >>     writeln(r);
> >>
> >>So, we'll need:
> >>     toJSON
> >>     toChars
> >
> >Shouldn't it just be toString()?
> 
> No. toString() returns a string, which has to be allocated. toChars()
> (an upcoming convention) would return an InputRange instead,
> side-stepping allocation.
[...]

??!  Surely you have heard of the non-allocating overload of toString?

	void toString(scope void delegate(const(char)[]) dg);


T

-- 
When solving a problem, take care that you do not become part of the problem.