Jump to page: 1 2
Thread overview
Why std_data_json is not default in phobos
Feb 20, 2018
aberba
Feb 20, 2018
aberba
Feb 20, 2018
bauss
Feb 20, 2018
Jonathan M Davis
Feb 20, 2018
aberba
Feb 20, 2018
Jonathan M Davis
Feb 21, 2018
Chris
Feb 22, 2018
aberba
Feb 22, 2018
Jonathan M Davis
Feb 22, 2018
aberba
Feb 22, 2018
Seb
Feb 22, 2018
Atila Neves
Feb 22, 2018
Jonathan M Davis
Feb 22, 2018
JN
Feb 22, 2018
Jonathan M Davis
Feb 22, 2018
Seb
Feb 22, 2018
rikki cattermole
Feb 22, 2018
Seb
February 20, 2018
I've taken a close look at the Api and its looks good. Its been around for a while. Why is it not yet in phobos?

https://code.dlang.org/packages/std_data_json
February 20, 2018
On Tuesday, 20 February 2018 at 09:20:15 UTC, aberba wrote:
> I've taken a close look at the Api and its looks good. Its been around for a while. Why is it not yet in phobos?
>
> https://code.dlang.org/packages/std_data_json

To add some context,  it was proposed in 2015 for review [1] and some insightful feedbacks were given in the thread. Along discussion. RC allocator seem to be in good shape in the 2.79 dmd release. Some naming conventions too.



[1] https://forum.dlang.org/thread/nbuhouhimowvcqssvfnr@forum.dlang.org?page=1
February 20, 2018
On Tuesday, 20 February 2018 at 09:20:15 UTC, aberba wrote:
> I've taken a close look at the Api and its looks good. Its been around for a while. Why is it not yet in phobos?
>
> https://code.dlang.org/packages/std_data_json

As far as I remember it's because Andrei isn't satisfied with the implementation, leading to disagreements in the design of the module.

-- Someone correct me if I'm wrong.
February 20, 2018
On Tuesday, February 20, 2018 11:55:54 bauss via Digitalmars-d wrote:
> On Tuesday, 20 February 2018 at 09:20:15 UTC, aberba wrote:
> > I've taken a close look at the Api and its looks good. Its been around for a while. Why is it not yet in phobos?
> >
> > https://code.dlang.org/packages/std_data_json
>
> As far as I remember it's because Andrei isn't satisfied with the implementation, leading to disagreements in the design of the module.
>
> -- Someone correct me if I'm wrong.

It is my understanding that there were disagreements of what the design should look like, so you're probably right, but regardless of the details, it didn't get far enough in the Phobos review process to come to a vote, and Sonke has not attempted to get it through the review process again. IIRC, I talked to Sonke about it at last year's dconf and came away with the impression that he'd given up on trying to get it into Phobos, but I don't know. I get the impression that a lot of folks who do anything that might be worth putting into Phobos don't want to go through the review process, and as dub and code.dlang.org have become more prevalent, I think that the motivation for folks to get any major piece of functionality into Phobos has decreased. So, while we've gotten new functions here and there, there hasn't been much in the way of new modules or seriouse rewrites of existing modules being proposed for official review for a while now.

- Jonathan M Davis

February 20, 2018
On Tuesday, 20 February 2018 at 12:10:35 UTC, Jonathan M Davis wrote:
> [...]

Hmm. I'm glad its available in dub. Not helpful to those not using dub though. Beginners too.
February 20, 2018
On Tuesday, February 20, 2018 15:08:04 aberba via Digitalmars-d wrote:
> On Tuesday, 20 February 2018 at 12:10:35 UTC, Jonathan M Davis
>
> wrote:
> > [...]
>
> Hmm. I'm glad its available in dub. Not helpful to those not using dub though. Beginners too.

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.

However, as for avoiding dub, some folks do, but really, the D ecosystem as a whole is going in the direction of using dub such that dub is _the_ way that folks make libraries available. So, anyone refusing to use dub is going to be hamstringing themselves in terms of having access to third party libraries, and even if one thing that they need is in the standard library, something else isn't going to be. It _is_ possible to use such libraries without dub; it's just more of a pain, and whether it's worth the effort depends on what you're doing. Hopefully, dub is improved so that those who have issues with it will be able to use it, but as it stands, anyone who wants to use 3rd party libraries in D without jumping through a bunch of hoops is going to have to use to dub with all of its pros and cons.

And from the standpoint of a library developer, with dub and code.dlang.org, they can just make their libraries available for others to use without jumping through any of the hoops necessary to get it into Phobos. So, unless they really want something in Phobos, it's just easier to make it available on code.dlang.org and not bother with trying to get it into Phobos.

- Jonathan M Davis

February 21, 2018
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:

>
> And from the standpoint of a library developer, with dub and code.dlang.org, they can just make their libraries available for others to use without jumping through any of the hoops necessary to get it into Phobos. So, unless they really want something in Phobos, it's just easier to make it available on code.dlang.org and not bother with trying to get it into Phobos.
>
> - Jonathan M Davis

I've noticed that things are going in that direction. Whether it's a good thing or a bad thing I can't tell, but I guess it's a natural development once a language is managed in a stricter and more consistent way. Maybe we should highlight the 3rd party libs a bit more so people get used to looking up things in 1. Phobos > 2. code.dlang.org.
February 22, 2018
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. Why you developed dxml
February 22, 2018
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

February 22, 2018
On Tuesday, 20 February 2018 at 15:08:04 UTC, aberba wrote:
> On Tuesday, 20 February 2018 at 12:10:35 UTC, Jonathan M Davis wrote:
>> [...]
>
> Hmm. I'm glad its available in dub. Not helpful to those not using dub though. Beginners too.

Well, you could vote for this PR:

https://github.com/dlang/phobos/pull/6111

The idea is to improve the status quo by add least noting that the std.json is old and that there are better alternatives.

(and also e.g. https://github.com/dlang/phobos/pull/6116 for std.net.curl)
« First   ‹ Prev
1 2