On Saturday, 1 August 2015 at 14:52:55 UTC, Sönke Ludwig wrote:
> 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

Thanks! But How to get access to elements that in result: {}
for example to: "name":"_system"

{"result":{"name":"_system","id":"76067","path":"database-6067","isSystem":true},"error":false,"code":200}

Could you also extend docs with code example.

On Saturday, 1 August 2015 at 14:52:55 UTC, Sönke Ludwig wrote:
> 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

connectInfo.statusCode = response["code"].get!int;

std.variant.VariantException@std\variant.d(1445): Variant: attempting to use incompatible types stdx.data.json.value.JSONValue and int

On Wednesday, 29 July 2015 at 15:22:06 UTC, Don wrote:
> On Tuesday, 28 July 2015 at 22:29:01 UTC, Walter Bright wrote:
[snip]

> Related to this: it should not be importing std.bigint. Note that if std.bigint were fully implemented, it would be very heavyweight (optimal multiplication of enormous integers involves fast fourier transforms and all kinds of odd stuff, that's really bizarre to pull in if you're just parsing a trivial little JSON config file).
>
> Although it is possible for JSON to contain numbers which are larger than can fit into long or ulong, it's an abnormal case. Many apps (probably, almost all) will want to reject such numbers immediately. BigInt should be opt-in.
>
> And, it is also possible to have floating point numbers that are not representable in double or real. BigInt doesn't solve that case.
>
> It might be adequate to simply present it as a raw number (an unconverted string) if it isn't a built-in type. Parse it for validity, but don't actually convert it.

Actually JSON is defined as subset of EMCASCript-262 spec hence it may not ciontain anything other 64-bit5 IEEE-754 numbers period.
See:
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-terms-and-definitions-number-value
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ecmascript-language-types-number-type

Anything else is e-hm an "extension" (or simply put - violation of spec), I've certainly seen 64-bit integers in the wild - how often true big ints are found out there?

If no one can present some run of the mill REST JSON API breaking the rules I'd suggest demoting BigInt handling to optional feature.

Am 02.08.2015 um 19:14 schrieb Dmitry Olshansky:
>
> Actually JSON is defined as subset of EMCASCript-262 spec hence it may
> not ciontain anything other 64-bit5 IEEE-754 numbers period.
> See:
> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-terms-and-definitions-number-value
>
> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ecmascript-language-types-number-type
>
>
> Anything else is e-hm an "extension" (or simply put - violation of
> spec), I've certainly seen 64-bit integers in the wild - how often true
> big ints are found out there?
>
> If no one can present some run of the mill REST JSON API breaking the
> rules I'd suggest demoting BigInt handling to optional feature.
>
>

This is not true. Quoting from ECMA-404:

> JSON is a text format that facilitates structured data interchange between all programming languages. JSON
> is syntax of braces, brackets, colons, and commas that is useful in many contexts, profiles, and applications.
> JSON  was  inspired  by  the  object  literals  of  JavaScript  aka  ECMAScript  as  defined  in  the  ECMAScript
> Language   Specification,   third   Edition   [1].
> It  does  not  attempt  to  impose  ECMAScript’s  internal  data
> representations on other programming languages. Instead, it shares a small subset of ECMAScript’s textual
> representations with all other programming languages.
> JSON  is  agnostic  about  numbers.  In  any  programming  language,  there  can  be  a  variety  of  number  types  of
> various capacities and complements, fixed or floating, binary or decimal. That can make interchange between
> different  programming  languages  difficult.  JSON  instead  offers  only  the  representation  of  numbers  that
> humans use: a sequence  of digits.  All programming languages know  how to make sense of digit sequences
> even if they disagree on internal representations. That is enough to allow interchange.

On 03-Aug-2015 10:56, Sönke Ludwig wrote:
> Am 02.08.2015 um 19:14 schrieb Dmitry Olshansky:
>>
>> Actually JSON is defined as subset of EMCASCript-262 spec hence it may
>> not ciontain anything other 64-bit5 IEEE-754 numbers period.
>> See:
>> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-terms-and-definitions-number-value
>>
>>
>> http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ecmascript-language-types-number-type
>>
>>
>>
>> Anything else is e-hm an "extension" (or simply put - violation of
>> spec), I've certainly seen 64-bit integers in the wild - how often true
>> big ints are found out there?
>>
>> If no one can present some run of the mill REST JSON API breaking the
>> rules I'd suggest demoting BigInt handling to optional feature.
>>
>>
>
> This is not true. Quoting from ECMA-404:
>
>> JSON is a text format that facilitates structured data interchange
>> between all programming languages. JSON
>> is syntax of braces, brackets, colons, and commas that is useful in
>> many contexts, profiles, and applications.
>> JSON  was  inspired  by  the  object  literals  of  JavaScript  aka
>> ECMAScript  as  defined  in  the  ECMAScript
>> Language   Specification,   third   Edition   [1].
>> It  does  not  attempt  to  impose  ECMAScript’s  internal  data
>> representations on other programming languages. Instead, it shares a
>> small subset of ECMAScript’s textual
>> representations with all other programming languages.
>> JSON  is  agnostic  about  numbers.  In  any  programming  language,
>> there  can  be  a  variety  of  number  types  of
>> various capacities and complements, fixed or floating, binary or
>> decimal. That can make interchange between
>> different  programming  languages  difficult.  JSON  instead  offers
>> only  the  representation  of  numbers  that
>> humans use: a sequence  of digits.  All programming languages know
>> how to make sense of digit sequences
>> even if they disagree on internal representations. That is enough to
>> allow interchange.

Hm about 5 solid pages and indeed it leaves everything unspecified for extensibility so I stand corrected.
Still I'm more inclined to put my trust in RFCs, such as the new one:
http://www.ietf.org/rfc/rfc7159.txt

Which states:

   This specification allows implementations to set limits on the range
   and precision of numbers accepted.  Since software that implements
   IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is
   generally available and widely used, good interoperability can be
   achieved by implementations that expect no more precision or range
   than these provide, in the sense that implementations will
   approximate JSON numbers within the expected precision.  A JSON
   number such as 1E400 or 3.141592653589793238462643383279 may indicate
   potential interoperability problems, since it suggests that the
   software that created it expects receiving software to have greater
   capabilities for numeric magnitude and precision than is widely
   available.

   Note that when such software is used, numbers that are integers and
   are in the range [-(2**53)+1, (2**53)-1] are interoperable in the
   sense that implementations will agree exactly on their numeric
   values.

And it implies setting limits on everything:

9.  Parsers

   A JSON parser transforms a JSON text into another representation.  A
   JSON parser MUST accept all texts that conform to the JSON grammar.
   A JSON parser MAY accept non-JSON forms or extensions.

   An implementation may set limits on the size of texts that it
   accepts.  An implementation may set limits on the maximum depth of
   nesting.  An implementation may set limits on the range and precision
   of numbers.  An implementation may set limits on the length and
   character contents of strings.


Now back to our land let's look at say rapidJSON.

It MAY seem to handle big integers:
https://github.com/miloyip/rapidjson/blob/master/include/rapidjson/internal/biginteger.h

But it's used only to parse doubles:
https://github.com/miloyip/rapidjson/pull/137

Anyhow the API says it all - only integers up to 64bit and doubles:

http://rapidjson.org/md_doc_sax.html#Handler

Pretty much what I expect by default.
And plz-plz don't hardcode BitInteger in JSON parser, it's slow plus it causes epic code bloat as Don already pointed out.

-- 
Dmitry Olshansky

On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
> Start of the two week process, folks.
>
> Code: https://github.com/s-ludwig/std_data_json
> Docs: http://s-ludwig.github.io/std_data_json/
>
> Atila

Looked in the doc ( http://s-ludwig.github.io/std_data_json/stdx/data/json/value/JSONValue.html ). I wanted to know how JSONValue can be manipulated. That is not very explicit.

First, it doesn't looks like the value can embed null as a value. null is a valid json value.

Secondly, it seems that it accept bigint. As per JSON spec, the only kind of numeric value you can have in there is a num, which doesn't even make the difference between floating point and integer (!) and with 53 bits of precision. By having double and long in there, we are already way over spec, so I'm not sure why we'd want to put bigint in there.

Finally, I'd love to see that JSONValue to exhibit a similar API than jsvar.

Am 03.08.2015 um 23:15 schrieb deadalnix:
> On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
>> Start of the two week process, folks.
>>
>> Code: https://github.com/s-ludwig/std_data_json
>> Docs: http://s-ludwig.github.io/std_data_json/
>>
>> Atila
>
> Looked in the doc (
> http://s-ludwig.github.io/std_data_json/stdx/data/json/value/JSONValue.html
> ). I wanted to know how JSONValue can be manipulated. That is not very
> explicit.
>
> First, it doesn't looks like the value can embed null as a value. null
> is a valid json value.

The documentation is lacking, I'll improve that. JSONValue includes an alias this to an Algebraic, which provides the actual data API. Its type list includes typeof(null).

>
> Secondly, it seems that it accept bigint. As per JSON spec, the only
> kind of numeric value you can have in there is a num, which doesn't even
> make the difference between floating point and integer (!) and with 53
> bits of precision. By having double and long in there, we are already
> way over spec, so I'm not sure why we'd want to put bigint in there.

See also my reply a few posts back. JSON does not specify anything WRT the precision or length of numbers. In the ECMA standard it is mentioned explicitly that this was done so that applications are not limited in what kind of numbers can be transferred. The only thing explicitly mentioned is that implementations *may* choose to support only 64-bit floats. But large integer numbers are used in practice, so we should be able to handle those, too (one way or another).

>
> Finally, I'd love to see that JSONValue to exhibit a similar API than
> jsvar.
>

This is how it used to be in the vibe.data.json module. I consider that to be a mistake now for multiple reasons, at least on this abstraction level. My proposal would be to have a clean, "strongly typed" JSONValue and a generic jsvar like struct on top of that, which is defined independently, and could for example work on a BSONValue, too. The usage would simply be "var value = parseJSONValue(...);".

On Tuesday, 4 August 2015 at 13:10:11 UTC, Sönke Ludwig wrote:
> This is how it used to be in the vibe.data.json module. I consider that to be a mistake now for multiple reasons, at least on this abstraction level. My proposal would be to have a clean, "strongly typed" JSONValue and a generic jsvar like struct on top of that, which is defined independently, and could for example work on a BSONValue, too. The usage would simply be "var value = parseJSONValue(...);".

That is not going to cut it. I've been working with these for ages. This is the very kind of scenarios where dynamically typed languages are way more convenient.

I've used both quite extensively and this is clear cut: you don't want what you call the strongly typed version of things. I've done it in many languages, including in java for instance.

jsvar interface remove the problematic parts of JS (use ~ instead of + for concat strings and do not implement the opDispatch part of the API).

On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
> Start of the two week process, folks.
>
> Code: https://github.com/s-ludwig/std_data_json
> Docs: http://s-ludwig.github.io/std_data_json/
>
> Atila

I forgot to give warnings that the two week period was about to be up, and was unsure from comments if this would be ready for voting, so let's give it another two days unless there are objections.

Atila

On Tuesday, 11 August 2015 at 17:08:39 UTC, Atila Neves wrote:
> On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote:
>> Start of the two week process, folks.
>>
>> Code: https://github.com/s-ludwig/std_data_json
>> Docs: http://s-ludwig.github.io/std_data_json/
>>
>> Atila
>
> I forgot to give warnings that the two week period was about to be up, and was unsure from comments if this would be ready for voting, so let's give it another two days unless there are objections.
>
> Atila

Ok some actionable items.

1/ How big is a JSON struct ? What is the biggest element in the union ? Is that element really needed ? Recurse.
2/ As far as I can see, the element are discriminated using typeid. An enum is preferable as the compiler would know values ahead of time and optimize based on this. It also allow use of things like final switch.
3/ Going from the untyped world to the typed world and provide an API to get back to the untyped word is a loser strategy. That sounds true intuitively, but also from my experience manipulating JSON in various languages. The Nodes produced by this lib need to be "manipulatable" as the unstructured values they represent.