Am 03.08.2014 17:34, schrieb Andrei Alexandrescu:
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.
Following our email exchange I decided to work on this because (a) you
mentioned more work is needed and your schedule was unclear, (b) we need
this at FB sooner rather than later, (c) there were a few things I
thought can be improved in vibe.data.json. I hope that taking
std.jgrandson to proof spurs things into action.
Would you want to merge some of std.jgrandson's deltas into a new
proposal std.data.json based on vibe.data.json? Here's a few things that
I consider necessary:
1. Commit to a schedule. I can't abandon stuff in wait for the perfect
design that may or may not come someday.
This may be the crux w.r.t. the vibe.data.json implementation. My
schedule will be very crowded this month, so I could only really start
to work on it beginning of September. But apart from the mentioned
points, I think your implementation is already the closest thing to what
I have in mind, so I'm all for going the clean slate route (I'll have to
do a lot in terms of deprecation work in vibe.d anyway).
2. Avoid UTF decoding.
3. Offer a lazy token stream as a basis for a non-lazy parser. A lazy
general parser would be considerably more difficult to write and would
only serve a small niche. On the other hand, a lazy tokenizer is easy to
write and make efficient, and serve as a basis for user-defined
specialized lazy parsers if the user wants so.
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.
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.
6. Address w0rp's issue with undefined. In fact std.Algebraic does have
an uninitialized state :o).
Sönke, what do you think?
My requirements would be the same, except for 6.
The "undefined" state in the vibe.d version was necessary due to early
API decisions and it's more or less a prominent part of it (specifically
because the API was designed to behave similar to JavaScript). In
hindsight, I'd definitely avoid that. However, I don't think its
existence (also in the form of Algebraic.init) is an issue per se, as
long as such values are properly handled when converting the runtime
value back to a JSON string (i.e. skipped or treated as null values).
