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