Hi.

struct RawGoogleResults
{
	string version_;
	string status;
	string sig;
	string[string][][string] table;
}

enum json = "{"version":"0.6","status":"ok","sig":"717451517","table":{"cols":[{"id":"date","label":"Date","type":"date","pattern":""},{"id":"query0","label":"euro crisis","type":"number","pattern":""}],"rows":[{"c":[{"v":"2004-01-02"),"f":"January 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-02-02"),"f":"February 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-03-02"),"f":"March 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-04-02")...

auto table = deserialize!(JsonSerializer, RawGoogleResults)(json);

I cannot pass a string to deserialize (the documentation suggests an input range should be fine):
http://vibed.org/api/vibe.data.serialization/deserialize

I have a feeling maybe deserialize doesn't do what I want, but what should I be using instead.  (I would like to parse the json and shove the results in the struct above).


Thanks.


Laeeth.

On Tuesday, 24 March 2015 at 04:53:39 UTC, Laeeth Isharc wrote:
> Hi.
>
> struct RawGoogleResults
> {
> 	string version_;
> 	string status;
> 	string sig;
> 	string[string][][string] table;
> }
>
> enum json = "{"version":"0.6","status":"ok","sig":"717451517","table":{"cols":[{"id":"date","label":"Date","type":"date","pattern":""},{"id":"query0","label":"euro crisis","type":"number","pattern":""}],"rows":[{"c":[{"v":"2004-01-02"),"f":"January 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-02-02"),"f":"February 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-03-02"),"f":"March 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-04-02")...
>
> auto table = deserialize!(JsonSerializer, RawGoogleResults)(json);
>
> I cannot pass a string to deserialize (the documentation suggests an input range should be fine):
> http://vibed.org/api/vibe.data.serialization/deserialize
>
> I have a feeling maybe deserialize doesn't do what I want, but what should I be using instead.  (I would like to parse the json and shove the results in the struct above).
>
>
> Thanks.
>
>
> Laeeth.

Okay - figured it out from the source code.

auto results = deserialize!(JsonStringSerializer!string, RawGoogleResults)(json);

and easier to write:

struct RawGoogleResults
{
	string version_;
	string status;
	string sig;
	//Json!array[string][][string] table;
	Json table;
}

On 24/03/2015 6:36 p.m., Laeeth Isharc wrote:
> On Tuesday, 24 March 2015 at 04:53:39 UTC, Laeeth Isharc wrote:
>> Hi.
>>
>> struct RawGoogleResults
>> {
>>     string version_;
>>     string status;
>>     string sig;
>>     string[string][][string] table;
>> }
>>
>> enum json =
>> "{"version":"0.6","status":"ok","sig":"717451517","table":{"cols":[{"id":"date","label":"Date","type":"date","pattern":""},{"id":"query0","label":"euro
>> crisis","type":"number","pattern":""}],"rows":[{"c":[{"v":"2004-01-02"),"f":"January
>> 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-02-02"),"f":"February
>> 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-03-02"),"f":"March
>> 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-04-02")...
>>
>> auto table = deserialize!(JsonSerializer, RawGoogleResults)(json);
>>
>> I cannot pass a string to deserialize (the documentation suggests an
>> input range should be fine):
>> http://vibed.org/api/vibe.data.serialization/deserialize
>>
>> I have a feeling maybe deserialize doesn't do what I want, but what
>> should I be using instead.  (I would like to parse the json and shove
>> the results in the struct above).
>>
>>
>> Thanks.
>>
>>
>> Laeeth.
>
> Okay - figured it out from the source code.
>
> auto results = deserialize!(JsonStringSerializer!string,
> RawGoogleResults)(json);
>
> and easier to write:
>
> struct RawGoogleResults
> {
>      string version_;
>      string status;
>      string sig;
>      //Json!array[string][][string] table;
>      Json table;
> }

Yeah, it is not very intuitive. But it works.

> Yeah, it is not very intuitive. But it works.

Thanks.

Next question - how can I correctly deal with inconsiderately chosen JSON field names like 'private' (which conflict in a struct declaration with D language keywords).  A hack is to do a search and replace on the JSON before presenting it to vibe.d, but I wondered if there was a better way.  Incidentally, vibe doesn't seem to like my replacing private with private_ - whereas privateX works.


Laeeth.

On Thursday, 26 March 2015 at 00:41:50 UTC, Laeeth Isharc wrote:
>> Yeah, it is not very intuitive. But it works.
>
> Thanks.
>
> Next question - how can I correctly deal with inconsiderately chosen JSON field names like 'private' (which conflict in a struct declaration with D language keywords).  A hack is to do a search and replace on the JSON before presenting it to vibe.d, but I wondered if there was a better way.  Incidentally, vibe doesn't seem to like my replacing private with private_ - whereas privateX works.
>
>
> Laeeth.

index-based access still should work, right? Like obj["private"]

On Thursday, 26 March 2015 at 00:41:50 UTC, Laeeth Isharc wrote:
>> Yeah, it is not very intuitive. But it works.
>
> Thanks.
>
> Next question - how can I correctly deal with inconsiderately chosen JSON field names like 'private' (which conflict in a struct declaration with D language keywords).  A hack is to do a search and replace on the JSON before presenting it to vibe.d, but I wondered if there was a better way.  Incidentally, vibe doesn't seem to like my replacing private with private_ - whereas privateX works.
>
>
> Laeeth.

Use the @name attribute:

http://vibed.org/api/vibe.data.serialization/name

On Thursday, 26 March 2015 at 01:04:06 UTC, Jakob Ovrum wrote:
> On Thursday, 26 March 2015 at 00:41:50 UTC, Laeeth Isharc wrote:
>>> Yeah, it is not very intuitive. But it works.
>>
>> Thanks.
>>
>> Next question - how can I correctly deal with inconsiderately chosen JSON field names like 'private' (which conflict in a struct declaration with D language keywords).  A hack is to do a search and replace on the JSON before presenting it to vibe.d, but I wondered if there was a better way.  Incidentally, vibe doesn't seem to like my replacing private with private_ - whereas privateX works.
>>
>>
>> Laeeth.
>
> Use the @name attribute:
>
> http://vibed.org/api/vibe.data.serialization/name

aha!  Thanks.  (and to dicebot - I am not sure index-based access works as the problem is in parsing stage, not accessing).

Am 24.03.2015 um 06:36 schrieb Laeeth Isharc:
> On Tuesday, 24 March 2015 at 04:53:39 UTC, Laeeth Isharc wrote:
>> Hi.
>>
>> struct RawGoogleResults
>> {
>>     string version_;
>>     string status;
>>     string sig;
>>     string[string][][string] table;
>> }
>>
>> enum json =
>> "{"version":"0.6","status":"ok","sig":"717451517","table":{"cols":[{"id":"date","label":"Date","type":"date","pattern":""},{"id":"query0","label":"euro
>> crisis","type":"number","pattern":""}],"rows":[{"c":[{"v":"2004-01-02"),"f":"January
>> 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-02-02"),"f":"February
>> 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-03-02"),"f":"March
>> 2004"},{"v":0.0,"f":"0"}]},{"c":[{"v":"2004-04-02")...
>>
>> auto table = deserialize!(JsonSerializer, RawGoogleResults)(json);
>>
>> I cannot pass a string to deserialize (the documentation suggests an
>> input range should be fine):
>> http://vibed.org/api/vibe.data.serialization/deserialize
>>
>> I have a feeling maybe deserialize doesn't do what I want, but what
>> should I be using instead.  (I would like to parse the json and shove
>> the results in the struct above).
>>
>>
>> Thanks.
>>
>>
>> Laeeth.
>
> Okay - figured it out from the source code.
>
> auto results = deserialize!(JsonStringSerializer!string,
> RawGoogleResults)(json);
>
> and easier to write:
>
> struct RawGoogleResults
> {
>      string version_;
>      string status;
>      string sig;
>      //Json!array[string][][string] table;
>      Json table;
> }
>

There is http://vibed.org/api/vibe.data.json/deserializeJson for this specific case. I'll mention that in the documentation of deserialize().

Am 26.03.2015 um 02:38 schrieb Laeeth Isharc:
> On Thursday, 26 March 2015 at 01:04:06 UTC, Jakob Ovrum wrote:
>> On Thursday, 26 March 2015 at 00:41:50 UTC, Laeeth Isharc wrote:
>>>> Yeah, it is not very intuitive. But it works.
>>>
>>> Thanks.
>>>
>>> Next question - how can I correctly deal with inconsiderately chosen
>>> JSON field names like 'private' (which conflict in a struct
>>> declaration with D language keywords).  A hack is to do a search and
>>> replace on the JSON before presenting it to vibe.d, but I wondered if
>>> there was a better way. Incidentally, vibe doesn't seem to like my
>>> replacing private with private_ - whereas privateX works.
>>>
>>>
>>> Laeeth.
>>
>> Use the @name attribute:
>>
>> http://vibed.org/api/vibe.data.serialization/name
>
> aha!  Thanks.  (and to dicebot - I am not sure index-based access works
> as the problem is in parsing stage, not accessing).

If I understood the issue correctly, there is also the possibility to append an underscore to the D field name in case of keyword conflicts:

struct S {
	int private_; // will be represented as "private"
}

This predated the @name attribute (and UDAs in general) and today the latter is probably more appropriate.

On Tuesday, 7 April 2015 at 22:15:13 UTC, Sönke Ludwig wrote:
> Am 26.03.2015 um 02:38 schrieb Laeeth Isharc:
>> On Thursday, 26 March 2015 at 01:04:06 UTC, Jakob Ovrum wrote:
>>> On Thursday, 26 March 2015 at 00:41:50 UTC, Laeeth Isharc wrote:
>>>>> Yeah, it is not very intuitive. But it works.
>>>>
>>>> Thanks.
>>>>
>>>> Next question - how can I correctly deal with inconsiderately chosen
>>>> JSON field names like 'private' (which conflict in a struct
>>>> declaration with D language keywords).  A hack is to do a search and
>>>> replace on the JSON before presenting it to vibe.d, but I wondered if
>>>> there was a better way. Incidentally, vibe doesn't seem to like my
>>>> replacing private with private_ - whereas privateX works.
>>>>
>>>>
>>>> Laeeth.
>>>
>>> Use the @name attribute:
>>>
>>> http://vibed.org/api/vibe.data.serialization/name
>>
>> aha!  Thanks.  (and to dicebot - I am not sure index-based access works
>> as the problem is in parsing stage, not accessing).
>
> If I understood the issue correctly, there is also the possibility to append an underscore to the D field name in case of keyword conflicts:
>
> struct S {
> 	int private_; // will be represented as "private"
> }
>
> This predated the @name attribute (and UDAs in general) and today the latter is probably more appropriate.

Thanks, Sonke.