July 30, 2015 Re: std.data.json formal review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Thu, Jul 30, 2015 at 12:43:40PM -0700, Walter Bright via Digitalmars-d wrote: > On 7/30/2015 9:58 AM, Brad Anderson wrote: > >If we can't have the minimal necessary module paths then I'm completely in favor of parseJSONStream over the more general parseStream. I want that "json" in there one way or another (preferably by the method which makes it optional while maintaining brevity). > > I would think it unlikely to be parsing two different formats in one file. But in any case, you can always do this: > > import std.data.json : parseJSON = parse; > > Or put the import in a scope: > > void doNaughtyThingsWithJson() > { > import std.data.json; > ... > x.parse(); > } > > The latter seems to be becoming the preferred D style. Yeah, local imports are fast becoming my preferred D coding style, because it makes code portable -- if you move a function to a new module, you don't have to untangle its import dependencies if all imports are local. It's one of those little, overlooked things about D that contribute toward making it an awesome language. T -- Written on the window of a clothing store: No shirt, no shoes, no service. |
July 30, 2015 Re: std.data.json formal review | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 7/30/2015 12:57 PM, H. S. Teoh via Digitalmars-d wrote:
> Yeah, local imports are fast becoming my preferred D coding style,
> because it makes code portable -- if you move a function to a new
> module, you don't have to untangle its import dependencies if all
> imports are local. It's one of those little, overlooked things about D
> that contribute toward making it an awesome language.
Funny how my preferred D style of writing code is steadily diverging from C++ style :-)
|
July 30, 2015 Re: std.data.json formal review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Thu, Jul 30, 2015 at 01:26:17PM -0700, Walter Bright via Digitalmars-d wrote: > On 7/30/2015 12:57 PM, H. S. Teoh via Digitalmars-d wrote: > >Yeah, local imports are fast becoming my preferred D coding style, because it makes code portable -- if you move a function to a new module, you don't have to untangle its import dependencies if all imports are local. It's one of those little, overlooked things about D that contribute toward making it an awesome language. > > Funny how my preferred D style of writing code is steadily diverging from C++ style :-) One would hope so, otherwise why are we here instead of in the C++ world? ;-) T -- This is not a sentence. |
July 31, 2015 Re: std.data.json formal review | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | is the current build is ready for production? I am getting error: source\stdx\data\json\value.d(81): Error: safe function 'stdx.data.json.value.JSONValue.this' cannot call system function 'std.variant.VariantN!(12u, typeof(null), bool, double, long, BigInt, string, JSONValue[], JSONValue[string]).VariantN.__ctor!(typeof(null)).this' |
July 31, 2015 Re: std.data.json formal review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suliman | Am 31.07.2015 um 10:13 schrieb Suliman:
> is the current build is ready for production? I am getting error:
>
> source\stdx\data\json\value.d(81): Error: safe function
> 'stdx.data.json.value.JSONValue.this' cannot call system function
> 'std.variant.VariantN!(12u, typeof(null), bool, double, long, BigInt,
> string, JSONValue[],
> JSONValue[string]).VariantN.__ctor!(typeof(null)).this'
2.068 "fixed" possible safety issues with VariantN by marking the interface @system instead of @trusted. Unfortunately that broke any @safe code using Variant/Algebraic.
|
July 31, 2015 Re: std.data.json formal review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | On Friday, 31 July 2015 at 12:16:02 UTC, Sönke Ludwig wrote: > Am 31.07.2015 um 10:13 schrieb Suliman: >> is the current build is ready for production? I am getting error: >> >> source\stdx\data\json\value.d(81): Error: safe function >> 'stdx.data.json.value.JSONValue.this' cannot call system function >> 'std.variant.VariantN!(12u, typeof(null), bool, double, long, BigInt, >> string, JSONValue[], >> JSONValue[string]).VariantN.__ctor!(typeof(null)).this' > > 2.068 "fixed" possible safety issues with VariantN by marking the interface @system instead of @trusted. Unfortunately that broke any @safe code using Variant/Algebraic. Wat revision are usable? I checked some and all have issue like: source\App.d(5,34): Error: template stdx.data.json.parser.parseJSONValue cannot deduce function from argument types !()(string), candidates are: source\stdx\data\json\parser.d(105,11): stdx.data.json.parser.parseJSONVa lue(LexOptions options = LexOptions.init, Input)(ref Input input, string filenam e = "") if (isStringInputRange!Input || isIntegralInputRange!Input) |
August 01, 2015 Re: std.data.json formal review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suliman | Am 31.07.2015 um 22:15 schrieb Suliman:
> On Friday, 31 July 2015 at 12:16:02 UTC, Sönke Ludwig wrote:
>> Am 31.07.2015 um 10:13 schrieb Suliman:
>>> is the current build is ready for production? I am getting error:
>>>
>>> source\stdx\data\json\value.d(81): Error: safe function
>>> 'stdx.data.json.value.JSONValue.this' cannot call system function
>>> 'std.variant.VariantN!(12u, typeof(null), bool, double, long, BigInt,
>>> string, JSONValue[],
>>> JSONValue[string]).VariantN.__ctor!(typeof(null)).this'
>>
>> 2.068 "fixed" possible safety issues with VariantN by marking the
>> interface @system instead of @trusted. Unfortunately that broke any
>> @safe code using Variant/Algebraic.
>
> Wat revision are usable? I checked some and all have issue like:
>
> source\App.d(5,34): Error: template stdx.data.json.parser.parseJSONValue
> cannot
> deduce function from argument types !()(string), candidates are:
> source\stdx\data\json\parser.d(105,11): stdx.data.json.parser.parseJSONVa
> lue(LexOptions options = LexOptions.init, Input)(ref Input input, string
> filenam
> e = "") if (isStringInputRange!Input || isIntegralInputRange!Input)
parseJSONValue takes a reference to an input range, so that it can consume the input and leave any trailing text after the JSON value in the range. For just converting a string to a JSONValue, use toJSONValue instead.
I'll make this more clear in the documentation.
|
August 01, 2015 Re: std.data.json formal review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sönke Ludwig | > parseJSONValue takes a reference to an input range, so that it can consume the input and leave any trailing text after the JSON value in the range. For just converting a string to a JSONValue, use toJSONValue instead. > > I'll make this more clear in the documentation. Yes please, because it's hard to understand difference. Maybe it's possible to simplify it more? Also I get trouble with extracting value: response = toJSONValue(res.bodyReader.readAllUTF8()); writeln(to!int(response["code"])); C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(295,24): Error: template std.c onv.toImpl cannot deduce function from argument types !(int)(VariantN!20u), cand idates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\conv.d(361,3): std.conv.toImpl (T, S)(S value) if (isImplicitlyConvertible!(S, T) && !isEnumStrToStr!(S, T) && !isNullToStr!(S, T)) If I am doing simple: writeln(response["code"]); Code produce right result (for example 200) What value consist in key "code"? It's look like not simple "200". How I can convert it to string or int? |
August 01, 2015 Re: std.data.json formal review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suliman | Look like it's Variant type. So I tried to use method get! do extract value from it writeln(get!(response["code"])); But I get error: Error: variable response cannot be read at compile time |
August 01, 2015 Re: std.data.json formal review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suliman | Am 01.08.2015 um 16:15 schrieb Suliman:
> Look like it's Variant type. So I tried to use method get! do extract
> value from it
> writeln(get!(response["code"]));
>
> But I get error: Error: variable response cannot be read at compile time
The correct syntax is: response["code"].get!int
|
Copyright © 1999-2021 by the D Language Foundation