std.xml and Adam D Ruppe's dom module

[Robert Jacques]

On Thu, 09 Feb 2012 05:13:52 -0600, Johannes Pfau <nospam at example.com> wrote:
> Am Wed, 08 Feb 2012 20:49:48 -0600
> schrieb "Robert Jacques" <sandford at jhu.edu>:
>>
>> Speaking as the one proposing said Json replacement, I'd like to
>> point out that JSON strings != UTF strings: manual conversion is
>> required some of the time. And I use appender as a dynamic buffer in
>> exactly the manner you suggest. There's even an option to use a
>> string cache to minimize total memory usage. (Hmm... that
>> functionality should probably be re-factored out and made into its
>> own utility) That said, I do end up doing a bunch of useless encodes
>> and decodes, so I'm going to special case those away and add slicing
>> support for strings. wstrings and dstring will still need to be
>> converted as currently Json values only accept strings and therefore
>> also Json tokens only support strings. As a potential user of the
>> sax/pull interface would you prefer the extra clutter of special side
>> channels for zero-copy wstrings and dstrings?
>
> BTW: Do you know DYAML?
> https://github.com/kiith-sa/D-YAML
>
> I think it has a pretty nice DOM implementation which doesn't require
> any changes to phobos. As YAML is a superset of JSON, adapting it for
> std.json shouldn't be too hard. The code is boost licensed and well
> documented.
>
> I think std.json would have better chances of being merged into phobos
> if it didn't rely on changes to std.variant.

I know about D-YAML, but haven't taken a deep look at it; it was developed long after I wrote my own JSON library. I did look into YAML before deciding to use JSON for my application; I just didn't need the extra features and implementing them would've taken extra dev time.

As for reliance on changes to std.variant, this was a change *suggested* by Andrei. And while it is the slower route to go, I believe it is the correct software engineering choice; prior to the change I was implementing my own typed union (i.e. I poorly reinvented std.variant) Actually, most of my initial work on Variant was to make its API just as good as my home-rolled JSON type. Furthermore, a quick check of the YAML code-base seems to indicate that underneath the hood, Variant is being used. I'm actually a little curious about what prevented YAML from being expressed using std.variant directly and if those limitations can be removed.

* The other thing slowing both std.variant and std.json down is my thesis writing :)