Re: std.data.json formal review

On Tuesday, October 9, 2018 5:45:02 PM MDT Nicholas Wilson via Digitalmars-d wrote: > On Tuesday, 9 October 2018 at 18:07:44 UTC, Márcio Martins wrote: > > On Tuesday, 28 July 2015 at 14:07:19 UTC, Atila Neves wrote: > >> Start of the two week process, folks. > >> > >> Code:

Re: std.data.json formal review

On Tuesday, 9 October 2018 at 18:07:44 UTC, Márcio Martins 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 Sorry for the late ping,

Re: std.data.json formal review

On Tuesday, 9 October 2018 at 18:07:44 UTC, Márcio Martins 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 Sorry for the late ping,

Re: std.data.json formal review

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 Sorry for the late ping, but it's been 3 years - what has happened to this? Has it been

Re: std.data.json formal review

On Tuesday, 6 October 2015 at 10:05:46 UTC, Alex wrote: I wonder if it would be better to write a more abstract serialisation/persistance module that could use either json,xml,some binary format and future formats. I think there are too many particulars making an abstract (de)serialization

Re: std.data.json formal review

JSON is a particular file format useful for serialising heirachical data. Given that D also has an XML module which appears to be deprecated, I wonder if it would be better to write a more abstract serialisation/persistance module that could use either json,xml,some binary format and future

Re: std.data.json formal review

Am 06.10.2015 um 12:05 schrieb Alex: JSON is a particular file format useful for serialising heirachical data. Given that D also has an XML module which appears to be deprecated, I wonder if it would be better to write a more abstract serialisation/persistance module that could use either

Re: std.data.json formal review

On Tuesday, 6 October 2015 at 15:47:08 UTC, Sebastiaan Koppe wrote: At which point it begs the question, why not just write simple primitive (de)serialization modules that only do one format? Probably easier to build, maintain and debug. The binary one is the one I care about, so that's the

Re: std.data.json formal review

Am Tue, 28 Jul 2015 14:07:18 + schrieb "Atila Neves" : > 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 There is one thing I noticed today that I personally feel

Re: std.data.json formal review

Am Tue, 29 Sep 2015 11:06:01 + schrieb Marc Schütz : > No, the JSON type should just store the raw unparsed token and > implement: > > struct JSON { > T to(T) if(isNumeric!T && is(typeof(T("" { > return T(this.raw); > } > } > >

Re: std.data.json formal review

On Monday, 28 September 2015 at 07:02:35 UTC, Marco Leise wrote: Am Tue, 18 Aug 2015 09:05:32 + schrieb "Marc Schütz" : Or, as above, leave it to the end user and provide a `to(T)` method that can support built-in types and `BigInt` alike. You mean the user should write

Re: std.data.json formal review

On Tuesday, 29 September 2015 at 11:06:03 UTC, Marc Schütz wrote: On Monday, 28 September 2015 at 07:02:35 UTC, Marco Leise wrote: Am Tue, 18 Aug 2015 09:05:32 + schrieb "Marc Schütz" : Or, as above, leave it to the end user and provide a `to(T)` method that can support

Re: std.data.json formal review

Am Tue, 18 Aug 2015 09:05:32 + schrieb "Marc Schütz" : > Or, as above, leave it to the end user and provide a `to(T)` > method that can support built-in types and `BigInt` alike. You mean the user should write a JSON number parsing routine on their own? Then which part is

Re: std.data.json formal review

On 27-Sep-2015 20:43, Marco Leise wrote: Am Mon, 03 Aug 2015 12:11:14 +0300 schrieb Dmitry Olshansky : [...] Now back to our land let's look at say rapidJSON. It MAY seem to handle big integers:

Re: std.data.json formal review

Am Mon, 03 Aug 2015 12:11:14 +0300 schrieb Dmitry Olshansky : > [...] > > 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

Re: std.data.json formal review

On Thursday, 24 September 2015 at 20:44:57 UTC, tired_eyes wrote: So, what is the current status of std.data.json? This topic is almost two month old, what is the result of "two week process"? Wiki page tells nothing except of "ready for comments". I probably should have posted here. Soenke

Re: std.data.json formal review

So, what is the current status of std.data.json? This topic is almost two month old, what is the result of "two week process"? Wiki page tells nothing except of "ready for comments".

Re: std.data.json formal review

On 08/25/2015 08:18 AM, Martin Nowak wrote: On 08/18/2015 12:21 AM, Andrei Alexandrescu wrote: * All new stuff should go in std.experimental. I assume stdx would change to that, should this work be merged. Though stdx (or better std.x) would have been a prettier and more exciting name for

Re: std.data.json formal review

On 8/25/15 11:02 AM, Timon Gehr wrote: On 08/25/2015 08:18 AM, Martin Nowak wrote: On 08/18/2015 12:21 AM, Andrei Alexandrescu wrote: * All new stuff should go in std.experimental. I assume stdx would change to that, should this work be merged. Though stdx (or better std.x) would have been a

Re: std.data.json formal review

On Saturday, 22 August 2015 at 13:41:49 UTC, Sönke Ludwig wrote: There is more than the actual call to validate(), such as writing tests and making sure the surroundings work, adjusting the interface and writing documentation. It's not *that* much work, but nonetheless wasted work. I also

Re: std.data.json formal review

On 08/18/2015 12:21 AM, Andrei Alexandrescu wrote: * All new stuff should go in std.experimental. I assume stdx would change to that, should this work be merged. Though stdx (or better std.x) would have been a prettier and more exciting name for std.experimental to begin with.

Re: std.data.json formal review

Am 24.08.2015 um 22:25 schrieb Walter Bright: On 8/22/2015 5:21 AM, Sönke Ludwig wrote: Am 17.08.2015 um 00:03 schrieb Walter Bright: D is going to be built around ranges as a fundamental way of coding. Users will need to learn something about them. Appending .array is not a big hill to climb.

Re: std.data.json formal review

On 08/25/2015 09:03 AM, Sönke Ludwig wrote: The performance benefit comes from the fact that almost all of JSON is a subset of ASCII, so that lexing the input will implicitly validate it as correct UTF. The only places where actual UTF sequences can occur is in string literals outside of

Re: std.data.json formal review

Am 25.08.2015 um 14:14 schrieb Sebastiaan Koppe: On Tuesday, 25 August 2015 at 06:56:23 UTC, Sönke Ludwig wrote: If I have a string variable and I want to store the upper case version of another string, the direct mental translation is dst = toUpper(src); - and not dst = toUpper(src).array;.

Re: std.data.json formal review

Am 25.08.2015 um 07:55 schrieb Martin Nowak: On Saturday, 22 August 2015 at 13:41:49 UTC, Sönke Ludwig wrote: There is more than the actual call to validate(), such as writing tests and making sure the surroundings work, adjusting the interface and writing documentation. It's not *that* much

Re: std.data.json formal review

Will try to convert a piece of code I wrote a few days ago. https://github.com/MartinNowak/rabbitmq-munin/blob/48c3e7451dec0dcb2b6dccbb9b4230b224e2e647/src/app.d Right now working with json for trivial stuff is a pain.

Re: std.data.json formal review

On Tuesday, 25 August 2015 at 06:56:23 UTC, Sönke Ludwig wrote: If I have a string variable and I want to store the upper case version of another string, the direct mental translation is dst = toUpper(src); - and not dst = toUpper(src).array;. One can also say the problem is that you have a

Re: std.data.json formal review

On 2015-08-21 18:25, Nick Sabalausky wrote: Module boundaries should be determined by organizational grouping, not by size. Well, but it depends on how you decide what should be in a group. Size is usually a part of that decision, although it might not be conscious. You wouldn't but the

Re: std.data.json formal review

On 8/22/2015 5:21 AM, Sönke Ludwig wrote: Am 17.08.2015 um 00:03 schrieb Walter Bright: D is going to be built around ranges as a fundamental way of coding. Users will need to learn something about them. Appending .array is not a big hill to climb. It isn't if you get taught about it. But it

Re: std.data.json formal review

Am 21.08.2015 um 18:54 schrieb Andrei Alexandrescu: On 8/19/15 4:55 AM, Sönke Ludwig wrote: Am 19.08.2015 um 03:58 schrieb Andrei Alexandrescu: On 8/18/15 1:24 PM, Jacob Carlborg wrote: On 2015-08-18 17:18, Andrei Alexandrescu wrote: Me neither if internal. I do see a problem if it's

Re: std.data.json formal review

Am 17.08.2015 um 00:03 schrieb Walter Bright: On 8/16/2015 5:34 AM, Sönke Ludwig wrote: Am 16.08.2015 um 02:50 schrieb Walter Bright: if (isInputRange!R is(Unqual!(ElementEncodingType!R) == char)) I'm not a fan of more names for trivia, the deluge of names has its own costs. Good,

Re: std.data.json formal review

Am 21.08.2015 um 19:30 schrieb Andrei Alexandrescu: On 8/18/15 12:54 PM, Sönke Ludwig wrote: Am 18.08.2015 um 00:21 schrieb Andrei Alexandrescu: * On the face of it, dedicating 6 modules to such a small specification as JSON seems excessive. I'm thinking one module here. (As a simple point:

Re: std.data.json formal review

Am 21.08.2015 um 18:56 schrieb Andrei Alexandrescu: On 8/18/15 1:21 PM, Sönke Ludwig wrote: Am 18.08.2015 um 00:37 schrieb Andrei Alexandrescu: On 8/17/15 2:56 PM, Sönke Ludwig wrote: - The enum is useful to be able to identify the types outside of the D code itself. For example when

Re: std.data.json formal review

On 08/21/2015 12:29 PM, David Nadlinger wrote: On Friday, 21 August 2015 at 15:58:22 UTC, Nick Sabalausky wrote: It also fucks up UFCS, and I'm a huge fan of UFCS. Are you saying that import json : parseJSON = parse; foo.parseJSON.bar; does not work? Ok, fair point, although I was

Re: std.data.json formal review

On 8/18/15 1:21 PM, Sönke Ludwig wrote: Am 18.08.2015 um 00:37 schrieb Andrei Alexandrescu: On 8/17/15 2:56 PM, Sönke Ludwig wrote: - The enum is useful to be able to identify the types outside of the D code itself. For example when serializing the data to disk, or when communicating with C

Re: std.data.json formal review

On 07/30/2015 02:40 PM, Jacob Carlborg wrote: On 2015-07-30 06:41, Walter Bright wrote: I agree with your goal of readability. And if someone wants to write code that emphasizes it's JSON, they can write it as std.data.json.parseStream. (It's not about saving typing, it's about avoiding extra

Re: std.data.json formal review

On 08/14/2015 04:33 PM, Walter Bright wrote: That is, the ECMA 404 spec. There seems to be more than one JSON spec. www.ecma-international.org/.../files/.../ECMA-404.pdf Amusingly, that ECMA-404 link results in an actual HTTP 404.

Re: std.data.json formal review

On Friday, 21 August 2015 at 15:58:22 UTC, Nick Sabalausky wrote: It also fucks up UFCS, and I'm a huge fan of UFCS. Are you saying that import json : parseJSON = parse; foo.parseJSON.bar; does not work? – David

Re: std.data.json formal review

On 08/18/2015 09:18 AM, Andrei Alexandrescu wrote: On 8/18/15 2:31 AM, Jacob Carlborg wrote: I don't think this is excessive. We should strive to have small modules. We already have/had problems with std.algorithm and std.datetime, let's not repeat those mistakes. A module with 2000 lines is

Re: std.data.json formal review

On Friday, 21 August 2015 at 16:25:40 UTC, Nick Sabalausky wrote: Module boundaries should be determined by organizational grouping, not by size. By organizational grouping as well as encapsulation concerns. Modules are the smallest units of encapsulation in D, visibility-wise. — David

Re: std.data.json formal review

On 08/15/2015 01:03 AM, Walter Bright wrote: On 8/14/2015 9:58 PM, suliman wrote: On Friday, 14 August 2015 at 20:44:59 UTC, Walter Bright wrote: Config files will work fine with json format. Walter, and what I should to do for commenting stringin config for test purpose? How it's can be done

Re: std.data.json formal review

On 8/21/15 12:25 PM, Nick Sabalausky wrote: On 08/18/2015 09:18 AM, Andrei Alexandrescu wrote: On 8/18/15 2:31 AM, Jacob Carlborg wrote: I don't think this is excessive. We should strive to have small modules. We already have/had problems with std.algorithm and std.datetime, let's not repeat

Re: std.data.json formal review

On 8/19/15 4:55 AM, Sönke Ludwig wrote: Am 19.08.2015 um 03:58 schrieb Andrei Alexandrescu: On 8/18/15 1:24 PM, Jacob Carlborg wrote: On 2015-08-18 17:18, Andrei Alexandrescu wrote: Me neither if internal. I do see a problem if it's public. -- Andrei If it's public and those 20 lines are

Re: std.data.json formal review

On 8/21/15 3:22 PM, Andrei Alexandrescu wrote: On 8/21/15 2:50 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, Aug 21, 2015 at 02:21:06PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: On 8/21/15 2:03 PM, tired_eyes wrote: On Friday, 21 August 2015 at 17:30:43 UTC, Andrei Alexandrescu

Re: std.data.json formal review

On Fri, Aug 21, 2015 at 03:22:25PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: On 8/21/15 2:50 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, Aug 21, 2015 at 02:21:06PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: On 8/21/15 2:03 PM, tired_eyes wrote: On Friday, 21 August

Re: std.data.json formal review

On 8/21/15 2:50 PM, H. S. Teoh via Digitalmars-d wrote: On Fri, Aug 21, 2015 at 02:21:06PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: On 8/21/15 2:03 PM, tired_eyes wrote: On Friday, 21 August 2015 at 17:30:43 UTC, Andrei Alexandrescu wrote: We must accommodate a GC-less world. It's

Re: std.data.json formal review

On 8/21/15 1:30 PM, Andrei Alexandrescu wrote: So perhaps this is just a naming issue. The names don't suggest everything you said. What I see is parse a JSON stream and parse a JSON value. So I naturally assumed we're looking at consuming a full stream vs. consuming only one value off a stream

Re: std.data.json formal review

On 8/21/15 2:03 PM, tired_eyes wrote: On Friday, 21 August 2015 at 17:30:43 UTC, Andrei Alexandrescu wrote: We must accommodate a GC-less world. It's definitely time to acknowledge the GC as a brake that limits D adoption, and put our full thrust behind removing it. Andrei Wow. Just wow.

Re: std.data.json formal review

On 8/18/15 12:54 PM, Sönke Ludwig wrote: Am 18.08.2015 um 00:21 schrieb Andrei Alexandrescu: * On the face of it, dedicating 6 modules to such a small specification as JSON seems excessive. I'm thinking one module here. (As a simple point: who would ever want to import only foundation, which in

Re: std.data.json formal review

On Friday, 21 August 2015 at 17:30:43 UTC, Andrei Alexandrescu wrote: We must accommodate a GC-less world. It's definitely time to acknowledge the GC as a brake that limits D adoption, and put our full thrust behind removing it. Andrei Wow. Just wow.

Re: std.data.json formal review

On Fri, Aug 21, 2015 at 02:21:06PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: On 8/21/15 2:03 PM, tired_eyes wrote: On Friday, 21 August 2015 at 17:30:43 UTC, Andrei Alexandrescu wrote: We must accommodate a GC-less world. It's definitely time to acknowledge the GC as a brake that

Re: std.data.json formal review

On 08/18/2015 12:21 AM, Andrei Alexandrescu wrote: - JSONValue should offer a byToken range, which offers the contents of the value one token at a time. For example, [ 1, 2, 3 ] offers the '[' token followed by three numeric tokens with the respective values followed by the ']' token. What

Re: std.data.json formal review

On 8/19/15 8:42 AM, Timon Gehr wrote: On 08/18/2015 12:21 AM, Andrei Alexandrescu wrote: - JSONValue should offer a byToken range, which offers the contents of the value one token at a time. For example, [ 1, 2, 3 ] offers the '[' token followed by three numeric tokens with the respective

Re: std.data.json formal review

On 2015-08-19 19:29, Andrei Alexandrescu wrote: Forgot about those. The invariant is that byToken should return a sequence of tokens that, when parsed, produces the originating object. That should be possible without the comma tokens in this case? -- /Jacob Carlborg

Re: std.data.json formal review

On 8/19/15 1:59 PM, Jacob Carlborg wrote: On 2015-08-19 19:29, Andrei Alexandrescu wrote: Forgot about those. The invariant is that byToken should return a sequence of tokens that, when parsed, produces the originating object. That should be possible without the comma tokens in this case?

Re: std.data.json formal review

Am 19.08.2015 um 03:58 schrieb Andrei Alexandrescu: On 8/18/15 1:24 PM, Jacob Carlborg wrote: On 2015-08-18 17:18, Andrei Alexandrescu wrote: Me neither if internal. I do see a problem if it's public. -- Andrei If it's public and those 20 lines are useful on its own, I don't see a problem

Re: std.data.json formal review

On 19-Aug-2015 04:58, Andrei Alexandrescu wrote: On 8/18/15 1:24 PM, Jacob Carlborg wrote: On 2015-08-18 17:18, Andrei Alexandrescu wrote: Me neither if internal. I do see a problem if it's public. -- Andrei If it's public and those 20 lines are useful on its own, I don't see a problem with

Re: std.data.json formal review

On 18-Aug-2015 01:33, Andrei Alexandrescu wrote: On 8/17/15 2:47 PM, Dmitry Olshansky wrote: Actually one can combine the two: - use integer type tag for everything built-in - use pointer tag for what is not But a pointer tag can do everything that an integer tag does. -- Andrei albeit

Re: std.data.json formal review

On Monday, 17 August 2015 at 22:21:50 UTC, Andrei Alexandrescu wrote: * stdx.data.json.generator: I think the API for converting in-memory JSON values to strings needs to be redone, as follows: - JSONValue should offer a byToken range, which offers the contents of the value one token at a

Re: std.data.json formal review

Am Tue, 18 Aug 2015 09:10:25 + schrieb Marc Schütz schue...@gmx.net: On Monday, 17 August 2015 at 22:34:36 UTC, Andrei Alexandrescu wrote: On 8/17/15 2:51 PM, deadalnix wrote: From the compiler perspective, the tag is much nicer. Compiler can use jump table for instance. The

Re: std.data.json formal review

On 2015-08-18 00:21, Andrei Alexandrescu wrote: * On the face of it, dedicating 6 modules to such a small specification as JSON seems excessive. I'm thinking one module here. (As a simple point: who would ever want to import only foundation, which in turn has one exception type and one location

Re: std.data.json formal review

On 18-Aug-2015 19:35, Andrei Alexandrescu wrote: On 8/18/15 12:31 PM, Dmitry Olshansky wrote: On 18-Aug-2015 16:19, Andrei Alexandrescu wrote: On 8/18/15 2:55 AM, Dmitry Olshansky wrote: On 18-Aug-2015 01:33, Andrei Alexandrescu wrote: On 8/17/15 2:47 PM, Dmitry Olshansky wrote: Actually

Re: std.data.json formal review

On Tuesday, 18 August 2015 at 14:58:08 UTC, Andrei Alexandrescu wrote: That's a language issue - switch does not work with any pointers. I just submitted https://issues.dlang.org/show_bug.cgi?id=14931. -- Andrei No it is not. Is the set of values is not compact, no jump table.

Re: std.data.json formal review

Am 18.08.2015 um 00:21 schrieb Andrei Alexandrescu: I'll preface my review with a general comment. This API comes at an interesting juncture; we're striving as much as possible for interfaces that abstract away lifetime management, so they can be used comfortably with GC, or at high performance

Re: std.data.json formal review

Am 18.08.2015 um 00:37 schrieb Andrei Alexandrescu: On 8/17/15 2:56 PM, Sönke Ludwig wrote: - The enum is useful to be able to identify the types outside of the D code itself. For example when serializing the data to disk, or when communicating with C code. OK. - It enables the use of

Re: std.data.json formal review

On 2015-08-18 17:18, Andrei Alexandrescu wrote: Me neither if internal. I do see a problem if it's public. -- Andrei If it's public and those 20 lines are useful on its own, I don't see a problem with that either. -- /Jacob Carlborg

Re: std.data.json formal review

On Tuesday, 18 August 2015 at 16:22:20 UTC, Andrei Alexandrescu wrote: On 8/18/15 11:39 AM, Johannes Pfau wrote: No, this won't improve the ASM much: Enum values start at 0 and are consecutive. With a final switch they're also bounded. All these points do not apply to pointers. They don't

Re: std.data.json formal review

On 8/18/15 1:24 PM, Jacob Carlborg wrote: On 2015-08-18 17:18, Andrei Alexandrescu wrote: Me neither if internal. I do see a problem if it's public. -- Andrei If it's public and those 20 lines are useful on its own, I don't see a problem with that either. In this case at least they aren't.

Re: std.data.json formal review

On Monday, 17 August 2015 at 22:34:36 UTC, Andrei Alexandrescu wrote: On 8/17/15 2:51 PM, deadalnix wrote: From the compiler perspective, the tag is much nicer. Compiler can use jump table for instance. The pointer is a more direct conduit to a jump table. Not really, because it most

Re: std.data.json formal review

On 8/18/15 7:02 AM, Johannes Pfau wrote: Am Tue, 18 Aug 2015 09:10:25 + schrieb Marc Schütz schue...@gmx.net: On Monday, 17 August 2015 at 22:34:36 UTC, Andrei Alexandrescu wrote: On 8/17/15 2:51 PM, deadalnix wrote: From the compiler perspective, the tag is much nicer. Compiler can

Re: std.data.json formal review

On 8/18/15 2:55 AM, Dmitry Olshansky wrote: On 18-Aug-2015 01:33, Andrei Alexandrescu wrote: On 8/17/15 2:47 PM, Dmitry Olshansky wrote: Actually one can combine the two: - use integer type tag for everything built-in - use pointer tag for what is not But a pointer tag can do everything

Re: std.data.json formal review

On 8/18/15 5:10 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Monday, 17 August 2015 at 22:34:36 UTC, Andrei Alexandrescu wrote: On 8/17/15 2:51 PM, deadalnix wrote: From the compiler perspective, the tag is much nicer. Compiler can use jump table for instance. The pointer is

Re: std.data.json formal review

On 2015-08-18 15:18, Andrei Alexandrescu wrote: How about a module with 20? -- Andrei If it's used in several other modules, I don't see a problem with it. -- /Jacob Carlborg

Re: std.data.json formal review

On 8/18/15 2:31 AM, Jacob Carlborg wrote: On 2015-08-18 00:21, Andrei Alexandrescu wrote: * On the face of it, dedicating 6 modules to such a small specification as JSON seems excessive. I'm thinking one module here. (As a simple point: who would ever want to import only foundation, which in

Re: std.data.json formal review

On 8/18/15 12:31 PM, Dmitry Olshansky wrote: On 18-Aug-2015 16:19, Andrei Alexandrescu wrote: On 8/18/15 2:55 AM, Dmitry Olshansky wrote: On 18-Aug-2015 01:33, Andrei Alexandrescu wrote: On 8/17/15 2:47 PM, Dmitry Olshansky wrote: Actually one can combine the two: - use integer type tag for

Re: std.data.json formal review

On 8/18/15 9:31 AM, Jacob Carlborg wrote: On 2015-08-18 15:18, Andrei Alexandrescu wrote: How about a module with 20? -- Andrei If it's used in several other modules, I don't see a problem with it. Me neither if internal. I do see a problem if it's public. -- Andrei

Re: std.data.json formal review

On 18-Aug-2015 16:19, Andrei Alexandrescu wrote: On 8/18/15 2:55 AM, Dmitry Olshansky wrote: On 18-Aug-2015 01:33, Andrei Alexandrescu wrote: On 8/17/15 2:47 PM, Dmitry Olshansky wrote: Actually one can combine the two: - use integer type tag for everything built-in - use pointer tag for

Re: std.data.json formal review

On 8/18/15 11:39 AM, Johannes Pfau wrote: No, this won't improve the ASM much: Enum values start at 0 and are consecutive. With a final switch they're also bounded. All these points do not apply to pointers. They don't start at 0, are not guaranteed to be consecutive and likely can't be used

Re: std.data.json formal review

Am Tue, 18 Aug 2015 10:58:17 -0400 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: On 8/18/15 7:02 AM, Johannes Pfau wrote: Am Tue, 18 Aug 2015 09:10:25 + schrieb Marc Schütz schue...@gmx.net: On Monday, 17 August 2015 at 22:34:36 UTC, Andrei Alexandrescu wrote: On

Re: std.data.json formal review

Am 17.08.2015 um 22:58 schrieb Suliman: String is a valid range, but parseJSONValue takes a *reference* to a range, because it directly consumes the range and leaves anything that appears after the JSON value in the range. toJSON() on the other hand assumes that the JSON value occupies the whole

Re: std.data.json formal review

On 8/17/15 2:47 PM, Dmitry Olshansky wrote: Actually one can combine the two: - use integer type tag for everything built-in - use pointer tag for what is not But a pointer tag can do everything that an integer tag does. -- Andrei

Re: std.data.json formal review

On 8/17/15 2:51 PM, deadalnix wrote: From the compiler perspective, the tag is much nicer. Compiler can use jump table for instance. The pointer is a more direct conduit to a jump table. It is not a good solution for Variant (which needs to be able to represent arbitrary types) but if the

Re: std.data.json formal review

On 8/17/15 2:56 PM, Sönke Ludwig wrote: - The enum is useful to be able to identify the types outside of the D code itself. For example when serializing the data to disk, or when communicating with C code. OK. - It enables the use of pattern matching (final switch), which is often very

Re: std.data.json formal review

On 7/28/15 10:07 AM, 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'll preface my review with a general comment. This API comes at an interesting juncture; we're striving as much

Re: std.data.json formal review

On 7/28/15 10:07 AM, 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'll submit a review in short order, but thought this might be of use in performance comparisons:

Re: std.data.json formal review

On Monday, 17 August 2015 at 18:12:02 UTC, Andrei Alexandrescu wrote: On 8/14/15 7:40 AM, Andrei Alexandrescu wrote: On 8/12/15 5:43 AM, Sönke Ludwig wrote: Anyway, I've just started to work on a generic variant of an enum based algebraic type that exploits as much static type information as

Re: std.data.json formal review

On 17-Aug-2015 21:12, Andrei Alexandrescu wrote: On 8/14/15 7:40 AM, Andrei Alexandrescu wrote: On 8/12/15 5:43 AM, Sönke Ludwig wrote: Anyway, I've just started to work on a generic variant of an enum based algebraic type that exploits as much static type information as possible. If that

Re: std.data.json formal review

Am 17.08.2015 um 20:12 schrieb Andrei Alexandrescu: On 8/14/15 7:40 AM, Andrei Alexandrescu wrote: struct TaggedAlgebraic(U) if (is(U == union)) { ... } Interesting. I think it would be best to rename it to TaggedUnion (instantly recognizable; also TaggedAlgebraic is an oxymoron as there's no

Re: std.data.json formal review

On 8/14/15 7:40 AM, Andrei Alexandrescu wrote: On 8/12/15 5:43 AM, Sönke Ludwig wrote: Anyway, I've just started to work on a generic variant of an enum based algebraic type that exploits as much static type information as possible. If that works out (compiler bugs?), it would be a great thing

Re: std.data.json formal review

Am Mon, 17 Aug 2015 20:56:18 +0200 schrieb Sönke Ludwig slud...@outerproduct.org: Am 17.08.2015 um 20:12 schrieb Andrei Alexandrescu: On 8/14/15 7:40 AM, Andrei Alexandrescu wrote: struct TaggedAlgebraic(U) if (is(U == union)) { ... } Interesting. I think it would be best to rename it

Re: std.data.json formal review

Why not working: JSONValue x = parseJSONValue(`{a: true, b: test}`); but: string str = `{a: true, b: test}`; JSONValue x = parseJSONValue(str); work fine?

Re: std.data.json formal review

I've added some changes in the latest version (docs updated): - Switched to TaggedAlgebraic with full static operator forwarding - Removed toPrettyJSON (now the default), added GeneratorOptions.compact - The bigInt field in JSONValue is now stored as a pointer - Removed

Re: std.data.json formal review

Also could you look at theme http://stackoverflow.com/questions/32033817/how-to-insert-date-to-arangodb And suggest your variant or approve on of existent.

Re: std.data.json formal review

Also I can't build last build from git. I am getting error: source\stdx\data\json\value.d(25,8): Error: module taggedalgebraic is in file 'taggedalgebraic.d' which cannot be read

Re: std.data.json formal review

Am 17.08.2015 um 22:31 schrieb Suliman: Also I can't build last build from git. I am getting error: source\stdx\data\json\value.d(25,8): Error: module taggedalgebraic is in file 'taggedalgebraic.d' which cannot be read Do you use DUB to build? It should automatically download the

Re: std.data.json formal review

Am 17.08.2015 um 22:23 schrieb Suliman: On Monday, 17 August 2015 at 20:07:24 UTC, Sönke Ludwig wrote: toJSONValue() is the right function in this case. I've update the docs/examples to make that clearer. I think that I miss understanding conception of ranges. I reread docs but can't

Re: std.data.json formal review

String is a valid range, but parseJSONValue takes a *reference* to a range, because it directly consumes the range and leaves anything that appears after the JSON value in the range. toJSON() on the other hand assumes that the JSON value occupies the whole input range. Yeas, I understood,

Re: std.data.json formal review

Am 17.08.2015 um 21:32 schrieb Suliman: Why not working: JSONValue x = parseJSONValue(`{a: true, b: test}`); but: string str = `{a: true, b: test}`; JSONValue x = parseJSONValue(str); work fine? toJSONValue() is the right function in this case. I've update the docs/examples to make that

Re: std.data.json formal review

On Monday, 17 August 2015 at 20:07:24 UTC, Sönke Ludwig wrote: Am 17.08.2015 um 21:32 schrieb Suliman: Why not working: JSONValue x = parseJSONValue(`{a: true, b: test}`); but: string str = `{a: true, b: test}`; JSONValue x = parseJSONValue(str); work fine? toJSONValue() is the right

Re: std.data.json formal review

On 8/15/2015 11:52 PM, Dmitry Olshansky wrote: For instance combining decoding and character classification one may side-step generating the codepoint value itself (because now it doesn't have to produce it for the top-level algorithm). Perhaps, but I wouldn't be convinced without benchmarks

  1   2   3   >