deimos as a namespace for C bindings

[cpiker]

Hi Jacob

Thanks for the invite to discuss dstep topics here. This is the first time I've attempted to be more engaged with the D community and I have to say everyone I've messaged in the last two weeks has been extraordinarily helpful and, just plain nice. It's a great precedent to set and I hope it helps build a bigger D community.

On the topic of module names, the reason that I used deimos as the top level module name for my CDF wrappers is due to this diagram from the D wiki article of the same name.

|--- library name (repository root)
    |--- README.md
    |--- dub.sdl
    |--- C
        |--- foo.h
        |--- bar
            |--- baz.h
    |--- deimos
        |--- foo.d
        |--- bar
            |--- baz.d

I think that the deimos initiative predates dub, so directory names were meant to correspond more directly to module names in the early days. Given that the company that started D was 'Digital Mars' the name itself suggests that the original intent was that anything under phobos was going to be the standard library (since that's the big moon of Mars), anything under deimos was just a wrapper for existing system libraries. Real external D projects would be in neither of these categories.

Since existing system libraries already define a namespace there is little chance that C binding modules will have a namespace collision under deimos. Also suppose for a particular problem domain someone starts off in D by just making a plain C wrapper, around let's say spice. Later as more knowledge is gained a full up D implementation of spice is implemented. Without the deimos "namespace", how should we distinguish between the two? One of them would end up with the name spiced or something cute like that and the other would just be spice. The end user now has to investigate the two to see which better fits their needs.

It seemed cleaner to me if all the C wrappers were under deimos, so that when a person imports one of those modules they know what they are getting, just a bare bones binding. A root level package is expected to have true D features. Given this convention we would end up with two packages one named spice and the other deimos.spice. So the package that "owns the name" is the D one, as it should be, and not the binding.

I may have read too much into the diagram, but it seemed like a clever demarcation, and thus the alluded intent of the Wiki article. That's why I named the cdf wrappers deimos.cdf instead of just cdf. A considered choice, but maybe a naive one.

--
Chris

[jacob-carlborg]

Thanks for the invite to discuss dstep topics here. This is the first time I've attempted to be more engaged with the D community and I have to say everyone I've messaged in the last two weeks has been extraordinarily helpful and, just plain nice. It's a great precedent to set and I hope it helps build a bigger D community.

That's great to hear.

On the topic of module names, the reason that I used deimos as the top level module name for my CDF wrappers is due to this diagram from the D wiki article of the same name.

Ok, I see. It's not a big deal and as you mentioned, it predates Dub.

Later as more knowledge is gained a full up D implementation of spice is implemented. Without the deimos "namespace", how should we distinguish between the two? One of them would end up with the name spiced or something cute like that and the other would just be spice. The end user now has to investigate the two to see which better fits their needs.

Sure, that can happen. It can also happen that someone wants to create another set of bindings for the same library. We already have bindings for WinAPI in druntime but there's still a separate Dub project with bindings for WinAPI.

I don't think there's one simple answer for all this. I would not necessarily name the Dub package the same as the C project it contains bindings for. It depends on the name of the C library. I think there are many C libraries that have quite poor names. They name the library after what it does and prepend lib to it. Like libhttp, libyaml and so on. Having a Dub project just called http is a bit too generic for me. It's even worse with the Foundation framework on macOS. Having a Dub project just named foundation, I don't know if anyone would understand the connection to the Foundation framework.

Of course, everyone if free to do as they wish, I just pointed out the standard D conventions 😃.