std.data.json formal review

Rikki Cattermole via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 28 20:42:09 PDT 2015


On 29/07/2015 4:25 a.m., Mathias Lang via Digitalmars-d wrote:
> 2015-07-28 17:55 GMT+02:00 Brad Anderson via Digitalmars-d
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at 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.

Right now we just need a plan, and we're all good for std.data.json.
Doesn't need to implemented right now, but I'd rather we had a plan 
going forward to add allocators to it, then you know find out a year 
down the track that it would need a whole rewrite.


More information about the Digitalmars-d mailing list