Why std_data_json is not default in phobos

[Jonathan M Davis]

On Thursday, February 22, 2018 07:24:30 aberba via Digitalmars-d wrote:
> On Tuesday, 20 February 2018 at 21:53:59 UTC, Jonathan M Davis
>
> wrote:
> > On Tuesday, February 20, 2018 15:08:04 aberba via Digitalmars-d
> >
> > wrote:
> >> [...]
> >
> > Well, ideally, std.json would be replaced with something
> > better, but it does work, and there's always going to be stuff
> > outside of the standard library. Pretty much no matter what
> > you're doing, at some point, you're either going to have to use
> > a third party library for something that you need or write it
> > yourself (usually, some combination of both). And there are
> > plenty of standard libraries that don't have any kind of JSON
> > support.
> >
> > [...]
>
> Out of curiosity, do you work on serverside related stuff at work
> or something. I noticed you were using Java.

I did use Java in previous jobs, but I don't curently use it. In recent
years, I've done far more with C++ and D, and my current job mostly involves
D. And I would almost certainly turn down a job that involved much in the
way of Java unless I were desperate. It's just too primitive to be a
pleasant language to program in.

Most of the code that I've done in my career has been server side, assuming
that there is any client or server involved at all. In particular, I have
done _very_ little with browser-based technologies like javascript. The
closest that I've really done to something that would be client-side would
be a client that viewed video that it pulled from an NVR over the LAN in a
video security system, and that was a desktop application written in C++. In
any project that involved a browser, I've always been working on the server
side of things.

> Why you developed dxml

XML makes a lot of sense for several projects that I have. I wanted to have
a good XML parser for those projects, and it was clear that that wasn't
going to materialize on its own.

For instance, one project that I have that I'd like to get back to is
creating wrappers for Qt5 so that it can be used from D. That would be far
too error-prone and time-consuming to do by hand, so it involves code
generation, and my solution for that was to create description files for the
Qt headers so that the necessary C/C++ and D code could be generated from
them. Any improvements to the code would therefore involve improving the
code generation rather than having to edit a ton of code by hand (Daniel
Murphy also suggested that I parse the C++ code like he did when porting dmd
from C++ to D, so I'll probably automate the generation of the description
files later, but I wouldn't want parsing C++ code to be part of building the
library, and at least some manual tweaks of the description files may be
required).

I had originally thought to do those description files in JSON, but they
would have been incredibly verbose and ugly that way in comparison to what I
could do in XML, because XML is far more free-form, whereas everything in
JSON pretty much has to be a value, an array, or an associative array.
Initially, I'd used std_experimental_xml, and it worked, but I had to work
around bugs in it and make changes to my local copy that never made it into
the upstream repo, because it wasn't maintained. So, there was no way that I
could release anything that way, and I needed an XML parser that was
actually maintained and worked without local fixes. And for better or worse,
that meant writing my own XML parser, which also delays any projects
requiring an XML parser, but sometimes, you have to spend time on one
project in order to have the tools you need to complete another. Heck, even
the Qt5 wrappers are in that boat. I'm doing them, because there are a
couple of applications that I'd like to write that need Qt, not just because
I like the idea of being able to use Qt from D.

Also, while I would have preferred to spend my time on projects other than
an XML parser, I do actually like writing parsers.

- Jonathan M Davis