std.xml and Adam D Ruppe's dom module

[Johannes Pfau]

Am Thu, 09 Feb 2012 08:18:15 -0600
schrieb "Robert Jacques" <sandford at jhu.edu>:

> 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 know, I didn't mean to criticize. I just thought DYAML could give
some useful inspiration for the DOM api.

> 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.

Sure, I was only referring to DYAML cause the DOM is very similar. Just
remove some features and it would suit JSON very well. One problem is
that DYAML uses some older YAML version which isn't 100% compatible
with JSON, so it can't be used as a JSON parser. There's also no way to
tell it to generate only JSON compatible output (and AFAIK that's a
design decision and not simply a missing feature)
> 
> As for reliance on changes to std.variant, this was a change
> *suggested* by Andrei.
Ok, then those changes obviously make sense. I actually thought Andrei
didn't like some of those changes.

> 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.

I guess the custom Node type was only added to support additional
methods(isScalar, isSequence, isMapping, add, remove, removeAt) and I'm
not sure if those are supported on Variant (length, foreach, opIndex,
opIndexAssign), but IIRC those are supported in your new std.variant.
> 
> * The other thing slowing both std.variant and std.json down is my
> thesis writing :)