std.data.json formal review
Walter Bright via Digitalmars-d
digitalmars-d at puremagic.com
Fri Aug 14 01:17:00 PDT 2015
On 8/13/2015 11:52 PM, Sönke Ludwig wrote:
> Am 14.08.2015 um 02:26 schrieb Walter Bright:
>> On 8/13/2015 3:51 AM, Sönke Ludwig wrote:
>>> These were, AFAICS, the only major open issues (a decision for an
>>> opt() variant
>>> would be nice, but fortunately that's not a fundamental decision in
>>> any way).
>>
>> 1. What about the issue of having the API be a composable range interface?
>>
>> http://s-ludwig.github.io/std_data_json/stdx/data/json/lexer/lexJSON.html
>>
>> I.e. the input range should be the FIRST argument, not the last.
>
> Hm, it *is* the first function argument, just the last template argument.
Ok, my mistake. I didn't look at the others.
I don't know what 'isStringInputRange' is. Whatever it is, it should be a 'range
of char'.
>> 2. Why are integers acceptable as lexer input? The spec specifies Unicode.
> In this case, the lexer will perform on-the-fly UTF validation of the input. It
> can do so more efficiently than first validating the input using a wrapper
> range, because it has to check the value of most incoming code units anyway.
There is no reason to validate UTF-8 input. The only place where non-ASCII code
units can even legally appear is inside strings, and there they can just be
copied verbatim while looking for the end of the string.
>> 3. Why are there 4 functions that do the same thing?
>>
>> http://s-ludwig.github.io/std_data_json/stdx/data/json/generator.html
>>
>> After all, there already is a
>> http://s-ludwig.github.io/std_data_json/stdx/data/json/generator/GeneratorOptions.html
> There are two classes of functions that are not covered by GeneratorOptions:
> writing to a stream or returning a string.
Why do both? Always return an input range. If the user wants a string, he can
pipe the input range to a string generator, such as .array
> But you are right that pretty
> printing should be controlled by GeneratorOptions. I'll fix that. The suggestion
> to use pretty printing by default also sounds good.
Thanks
More information about the Digitalmars-d
mailing list