On 8/3/14, 8:51 AM, Johannes Pfau wrote:
Am Sun, 03 Aug 2014 08:34:20 -0700
schrieb Andrei Alexandrescu <seewebsiteforem...@erdani.org>:
On 8/3/14, 2:38 AM, Sönke Ludwig wrote:
[snip]
We need to address the matter of std.jgrandson competing with
vibe.data.json. Clearly at a point only one proposal will have to be
accepted so the other would be wasted work.
[...]
4. Avoid string allocation. String allocation can be replaced with
slices of the input when these two conditions are true: (a) input
type is string, immutable(byte)[], or immutable(ubyte)[]; (b) there
are no backslash-encoded sequences in the string, i.e. the input
string and the actual string are the same.
I think for the lowest level interface we could avoid allocation
completely:
The tokenizer could always return slices to the raw string, even if a
string contains backslash-encode sequences or if the token is a number.
Simply expose that as token.rawValue. Then add a function,
Token.decodeString() and token.decodeNumber() to actually decode the
numbers. decodeString could additionally support decoding into a buffer.
That works but not e.g. for File.byLine which reuses its internal
buffer. But it's a neat idea for arrays of immutable bytes.
If the input is not sliceable, read the input into an internal buffer
first and slice that buffer.
At that point the cost of decoding becomes negligible.
The main usecase for this is if you simply stream lots of data and you
only want to parse very little of it and skip over most content. Then
you don't need to decode the strings.
Awesome.
This is also true if you only
write a JSON formatter: No need to decode and encode the strings.
But wouldn't that still need to encode \n, \r, \t, \v?
5. Build on std.variant through and through. Again, anything that
doesn't work is a usability bug in std.variant, which was designed
for exactly this kind of stuff. Exposing the representation such that
user code benefits of the Algebraic's primitives may be desirable.
Variant uses TypeInfo internally, right?
No.
Andrei
