Serialization woes

Robert Jacques sandford at jhu.edu
Thu Apr 19 06:05:56 PDT 2012


On Wed, 18 Apr 2012 23:49:23 -0500, Masahiro Nakagawa <repeatedly at gmail.com> wrote:
> On Thursday, 19 April 2012 at 00:00:32 UTC, Robert Jacques wrote:
>> On Wed, 18 Apr 2012 10:05:57 -0500, Andrej Mitrovic
>> <andrej.mitrovich at gmail.com> wrote:
>>
>>> On 4/18/12, Robert Jacques <sandford at jhu.edu> wrote:
>>>> here are some results for your benchmark on
>>>> my own serializers:
>>>>
>>>> JSON serialize: 0.331831 s
>>>> JSON deserialize: 0.243893 s
>>>
>>> Hey Robert, I was trying out your JSON library a while ago ago
>>> (I
>>> didn't find a repository but just a newsgroup link to the
>>> sources),
>>> and the library seemed to be missing the JSON.to! template,
>>> even
>>> though it was documented. Maybe you have a link to the newer
>>> sources?
>>> Thanks.
>>>
>>
>> Thank you. Sorry, the example code got stale. When I switched
>> to using a Variant for JSON, the to! moved into Variant. So the
>> documentation example should read:
>>
>> Json     json = JSON.parse( "[1,2,3]" );    // Parse an input
>> range
>> MyStruct var  = json.to!MyStruct();         // De-serialize a
>> type
>>          json = JSON.from(var);             // Serialize a type
>>
>> enforce(JSON.isValid(json));                // Validate the
>> serialization
>> write("var.json", JSON.toStringHR(json));   // Write in a
>> "pretty" format
>>
>> json = JSON.parse( "{x:1,y:2,z:3}" );
>> assert( json.x + json.y == 3 );             // Perform
>> operations on a Json
>
> What is the status of this json module?
>
> I am now working on new D library and
> its library needs JSON data format.
>
> std.json is not usable at hard-use.
> I want your json library as a std.json.
>

It's almost ready for review, but is dependent on an updated std.variant which is close, but not quite ready for review. The issues with variant are in the documentation and submitting all the other patches to github (in progress). Json is missing a zero-overhead tokenizer. The currently tokenizer currently parses / D-ifies the inputs, which is safer/easier to use but slower. I've been (and still am) busy with my PhD thesis, which is why I haven't really pushed these forward (plus there's been more important things in the review queue).


More information about the Digitalmars-d mailing list