Jens Mueller wrote:
> Hi,
> 
> I wrote some guidelines for writing a Deimos interface. It's still very
> rough but it's a start. I'd like to add it to dlang.org to give
> contributors better guidance, ultimately hoping to see more
> contributions to Deimos.
> Besides comments to improve my poor phrasing I'd especially seek to get
> a complete list of recommendations to follow. Please comment.
> 
> http://jkm.github.com/phobos/deimos.html

I believe I included all the change requests. Many thanks for the
feedback.
Updated version is at
http://jkm.github.com/d-programming-language.org/deimos.html

You can also create pull requests by using "Improve this page".

BTW why is there no documentation for core.stdc and core.sys on http://dlang.org/phobos/index.html? I wanted to create links to those packages.

Jens

On 2013-03-22 00:01, Jens Mueller wrote:

> I believe I included all the change requests. Many thanks for the
> feedback.
> Updated version is at
> http://jkm.github.com/d-programming-language.org/deimos.html

"Each #include <path/to/header.h> needs to have at most one corresponding import path.to.header;"

"at most one", is not correct. As we said, one may need several imports to cover a single include. It may also be possible to skip some includes due to the corresponding functionality being built in to the language or available in object.d

-- 
/Jacob Carlborg

Jacob Carlborg wrote:
> On 2013-03-22 00:01, Jens Mueller wrote:
> 
> >I believe I included all the change requests. Many thanks for the
> >feedback.
> >Updated version is at
> >http://jkm.github.com/d-programming-language.org/deimos.html
> 
> "Each #include <path/to/header.h> needs to have at most one corresponding import path.to.header;"
> 
> "at most one", is not correct. As we said, one may need several imports to cover a single include. It may also be possible to skip some includes due to the corresponding functionality being built in to the language or available in object.d

Skipping (bool, ...) is covered by "at most one", isn't it? Do you have an example where one C include results in several D imports?

Jens

On 2013-03-22 09:33, Jens Mueller wrote:

> Skipping (bool, ...) is covered by "at most one", isn't it? Do you have
> an example where one C include results in several D imports?

// a.h
int a;

// b.h
#include <a.h>

// main.c
#include <b.h>

int main (int c, char** v) { a = 3; }

The above should work. If you translate that code to D and only replaces the include with one import you won't have access to the "a" variable.

-- 
/Jacob Carlborg

On Friday, 22 March 2013 at 10:13:15 UTC, Jacob Carlborg wrote:
> On 2013-03-22 09:33, Jens Mueller wrote:
>
>> Skipping (bool, ...) is covered by "at most one", isn't it? Do you have
>> an example where one C include results in several D imports?
>
> // a.h
> int a;
>
> // b.h
> #include <a.h>
>
> // main.c
> #include <b.h>
>
> int main (int c, char** v) { a = 3; }
>
> The above should work. If you translate that code to D and only replaces the include with one import you won't have access to the "a" variable.

Shouldn't all C includes become public imports?

Jacob Carlborg wrote:
> On 2013-03-22 09:33, Jens Mueller wrote:
> 
> >Skipping (bool, ...) is covered by "at most one", isn't it? Do you have an example where one C include results in several D imports?
> 
> // a.h
> int a;
> 
> // b.h
> #include <a.h>
> 
> // main.c
> #include <b.h>
> 
> int main (int c, char** v) { a = 3; }
> 
> The above should work. If you translate that code to D and only replaces the include with one import you won't have access to the "a" variable.

True. But shouldn't you fix those things as follows:

module deimos.a;
int a;

(BTW Probably we should add shared here?)

module deimos.b;
public import deimos.a; // shouldn't this fix the problem

Does this work?
Should I add text about when to use public imports?

Jens

On 2013-03-22 11:15, Dicebot wrote:

> Shouldn't all C includes become public imports?

I would hate that. That's on of the beauties with D, that the imports are _not_ public.

-- 
/Jacob Carlborg

On 2013-03-22 11:53, Jens Mueller wrote:

> True. But shouldn't you fix those things as follows:
>
> module deimos.a;
> int a;
>
> (BTW Probably we should add shared here?)

__gshared.

> module deimos.b;
> public import deimos.a; // shouldn't this fix the problem
>
> Does this work?
> Should I add text about when to use public imports?

It would work but I think this is bad practice. I would hate that to happened with every C binding. I love that D imports are _not_ public.

-- 
/Jacob Carlborg

On Friday, 22 March 2013 at 12:14:07 UTC, Jacob Carlborg wrote:
> On 2013-03-22 11:15, Dicebot wrote:
>
>> Shouldn't all C includes become public imports?
>
> I would hate that. That's on of the beauties with D, that the imports are _not_ public.

Yes, but C header translations are not D and should try to mimic behavior that is translated. In C there are no non-public includes, so it sounds pretty natural. Unless root module itself is not imported publically, this should not created any problems for user code.

On 2013-03-22 13:34, Dicebot wrote:

> Yes, but C header translations are not D and should try to mimic
> behavior that is translated. In C there are no non-public includes, so
> it sounds pretty natural. Unless root module itself is not imported
> publically, this should not created any problems for user code.

BTW, I think it's bad style in C to depend on public includes in general. It do have it's uses cases just as public imports have in D.

-- 
/Jacob Carlborg