std_data_json
std_data_json copied to clipboard
dlang-community
Status on std.data.json for Phobos
On Thursday, 5 February 2015 at 17:26:34 UTC, Sönke Ludwig wrote:
Am 05.02.2015 um 10:07 schrieb Jakob Ovrum:
Added to the review queue as a work in progress with relevant links:
http://wiki.dlang.org/Review_QueueThanks! I(t) should be ready for an official review in one or two weeks when my schedule relaxes a little bit.
Any news on your progress to get this into Phobos?
This is mainly blocked by:
- Creating an
JSONInputRange, which converts aJSONValue, token or parser node range to its textual representation - Adding support for other string types (
rcstringin particular`) - I'm waiting until the whole RC discussion has produced some concrete results - Add more lazy literal parsing support
Creating an JSONInputRange
How about using Fibers and yield? This would make it easy to store the stack. If needed you can plug a small buffer around it.
Adding support for other string types
Do you know about this? https://github.com/burner/std.rcstring
I'm waiting until the whole RC discussion has produced some concrete results
Is this really blocking this proposal - it feels like if rcstring comes to Phobos, we still can add built-in support?
Add more lazy literal parsing support
What exactly do you mean by this? Doesn't the lexer already accept an Input Range?
How about using Fibers and yield? This would make it easy to store the stack. If needed you can plug a small buffer around it.
That would be too slow. The general impression from the reviews was that we need to have the fastest implementation in the world...
Do you know about this? https://github.com/burner/std.rcstring
Yes, although I've never used it. I guess it isn't usable together with Appender, though, which is one of the uncertainties.
Is this really blocking this proposal - it feels like if rcstring comes to Phobos, we still can add built-in support?
At least Andrei feels pretty strongly about this, but also depending on how the final RC design will be, it could mean some deep changes are required to add support, which may be difficult to do with a proper deprecation path.
What exactly do you mean by this? Doesn't the lexer already accept an Input Range?
Mainly lexing of string and number tokens. If they are not used, they can possibly be skipped faster and more importantly without using any memory allocations.
How's it going with this? We are currently noticing a need for a fast (well, or not incredibly slow like std.json) json parser implementation, and it's a bit sad that we can't use one in the stdlib, especially since it's been an open task for three years.
Phobos is in a feature freeze, so don't expect ANYTHING being added there.
Why can't you use this module?
I mean, I'm gonna. I'm just saying it's a bit sad that I can't use it in phobos rather than in dub.
PS: Apropos, hi! Dub review pls!