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

On 29/07/2015 2:07 a.m., 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

Right now, my view is no.
Unless there is some sort of proof that it will work with allocators.

I have used the code from vibe.d days so its not an issue of how well it works nor nit picky. Just can I pass it an allocator (optionally) and have it use that for all memory usage?

After all, I really would rather be able to deallocate all memory allocated during a request then you know, rely on the GC.

On Tuesday, 28 July 2015 at 15:07:46 UTC, Rikki Cattermole wrote:
> On 29/07/2015 2:07 a.m., 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
>
> Right now, my view is no.
> Unless there is some sort of proof that it will work with allocators.
>
> I have used the code from vibe.d days so its not an issue of how well it works nor nit picky. Just can I pass it an allocator (optionally) and have it use that for all memory usage?
>
> After all, I really would rather be able to deallocate all memory allocated during a request then you know, rely on the GC.

I totally agree with that, but shouldn't it be consistent in Phobos? I don't think it's possible to make an interface for custom allocators right now, because that question simply hasn't been ironed out along with std.allocator.

So, anything related to allocators belongs in another thread imo, and the review process here would be about the actual json interface

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

This is cool:
https://github.com/s-ludwig/std_data_json/blob/aac6d846d596750623fd5c546343f4f9d19447fa/source/stdx/data/json/value.d#L183

I was getting tired of programmatically checking for null, then checking for object type, before moving along in the object and doing the same recursively. Not quite as intuitive as the optional chaining ?. operator in swift but it gets pretty close https://blog.sabintsev.com/optionals-in-swift-c94fd231e7a4#5622

On Tuesday, 28 July 2015 at 15:07:46 UTC, Rikki Cattermole wrote:
> On 29/07/2015 2:07 a.m., 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
>
> Right now, my view is no.

Just a reminder that this is the review thread, not the vote thread (in case anyone reading got confused).

> Unless there is some sort of proof that it will work with allocators.
>
> I have used the code from vibe.d days so its not an issue of how well it works nor nit picky. Just can I pass it an allocator (optionally) and have it use that for all memory usage?
>
> After all, I really would rather be able to deallocate all memory allocated during a request then you know, rely on the GC.

That's a good point. This is the perfect opportunity to hammer out how allocators are going to be integrated into other parts of Phobos.

On Tuesday, 28 July 2015 at 15:55:04 UTC, Brad Anderson wrote:
> On Tuesday, 28 July 2015 at 15:07:46 UTC, Rikki Cattermole wrote:
>> On 29/07/2015 2:07 a.m., 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
>>
>> Right now, my view is no.
>
> Just a reminder that this is the review thread, not the vote thread (in case anyone reading got confused).
>
>> Unless there is some sort of proof that it will work with allocators.
>>
>> I have used the code from vibe.d days so its not an issue of how well it works nor nit picky. Just can I pass it an allocator (optionally) and have it use that for all memory usage?
>>
>> After all, I really would rather be able to deallocate all memory allocated during a request then you know, rely on the GC.
>
> That's a good point. This is the perfect opportunity to hammer out how allocators are going to be integrated into other parts of Phobos.

From what I see from std.allocator, there's no Allocator interface? I think this would require changing the type to `struct JSONValue(Allocator)`, unless we see an actual interface implemented in phobos.

2015-07-28 17:55 GMT+02:00 Brad Anderson via Digitalmars-d < digitalmars-d@puremagic.com>:

>
>  Unless there is some sort of proof that it will work with allocators.
>>
>> I have used the code from vibe.d days so its not an issue of how well it works nor nit picky. Just can I pass it an allocator (optionally) and have it use that for all memory usage?
>>
>> After all, I really would rather be able to deallocate all memory allocated during a request then you know, rely on the GC.
>>
>
> That's a good point. This is the perfect opportunity to hammer out how allocators are going to be integrated into other parts of Phobos.
>

Allocator is definitely a separate issue. It's a moving target, it's not
yet part of a release, and consequently barely field-tested. We will find
bugs, we might find design mistakes, we might head in a direction which
will turn out to be an anti-pattern (just like `opDispatch` for JSONValue
;) )
It's not to say the quality of the module isn't good - that would mean our
release process is broken -, but making a module inclusion to experimental
dependent on another module in experimental will not improve the quality of
the reviewed module.

Am 28.07.2015 um 17:07 schrieb Rikki Cattermole:
> On 29/07/2015 2:07 a.m., 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
>
> Right now, my view is no.
> Unless there is some sort of proof that it will work with allocators.
>
> I have used the code from vibe.d days so its not an issue of how well it
> works nor nit picky. Just can I pass it an allocator (optionally) and
> have it use that for all memory usage?
>
> After all, I really would rather be able to deallocate all memory
> allocated during a request then you know, rely on the GC.

If you pass a string or byte array as input, then there will be no allocations at all (the interface is @nogc).

For other cases it supports custom allocation through an appender factory [1][2], since there is no standard allocator interface, yet. But since that's the only place where memory is allocated (apart from lower level code, such as BigInt), as soon as Appender supports custom allocators, or you write your own appender, the JSON parser will, too.

Only if you use the DOM parser, there will be some inevitable GC allocations, because the DOM representation uses dynamic and associative arrays.

1: https://github.com/s-ludwig/std_data_json/blob/aac6d846d596750623fd5c546343f4f9d19447fa/source/stdx/data/json/lexer.d#L66
2: https://github.com/s-ludwig/std_data_json/blob/aac6d846d596750623fd5c546343f4f9d19447fa/source/stdx/data/json/parser.d#L286

Am 28.07.2015 um 17:07 schrieb Rikki Cattermole:
> I have used the code from vibe.d days so its not an issue of how well it
> works nor nit picky.

You should still have a closer look, as it isn't very similar to the vibe.d code at all, but a rather radical evolution.

Am 28.07.2015 um 16:07 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

Thanks for making it happen! Can you also post a quick link to this thread in D.announce?