Philosophy of how OS API imports are laid out in druntime

Walter Bright newshound2 at digitalmars.com
Thu Mar 6 16:53:19 PST 2014


On 3/6/2014 3:51 PM, Iain Buclaw wrote:
> On 6 March 2014 22:53, Walter Bright <newshound2 at digitalmars.com> wrote:
>> 1. Trying to reinvent, improve, refactor, fix, clean up, etc., the OS api.
>> This is not in D's charter. We have no resources to do it properly anyway.
>
> I don't think that is what druntime does in terms of it's C
> interfacing modules.

Usually not. But proposals to do such come up now and then - I just want to head 
these off before anyone invests effort in it.


> What it does do is make it more logical for
> people to find what they are looking for, or if they want to make
> changes, which areas to look at.

Eh, "more logical" is a trap. I'd prefer a simple 1:1 correspondence between C 
and D for OS api's. Then there's nothing clever about it, no decisions to make, 
and the user familiar with C will know where it is.


>> 2. Trying to split C's header files into separate posix / nonposix modules.
>> As in (1), this is beyond the scope of what D is trying to do.
>>
>
> I think the word posix seems to be the cesspool that's repeatedly
> brought up here to fan the flames here.   What about the
> linux/freebsd/osx/windows packages?

Eliminate the linux/freebsd/osx/windows package inventions. I don't see in C code:

     #include <sys/linux/sys/foo.h>

so why should we do that? Again, what I propose is really simple from a user 
point of view - a 1:1 mapping between what he'd type in for C vs what he'd type 
in for D.


>> 3. Pushing versioning into user code, as in:
>>
>>      version (linux) import os.linux.whatever;
>>      else version (FreeBSD) import os.freebsd.whatever;
>>      ...
>>      else static assert(0);
>>
>> as opposed to:
>>
>>      import os.whatever;
>>
>> I understand the sentiment that this will signal to the user that he's using
>> non-portable imports, but I don't think it's worth it. Portability is what
>> Phobos is for, not OS api interfaces.
>>
>
> This is something that needs to be worked on, but I'm not convinced a
> flat hierachy will solve anything.

What it will solve is when the user reads the OS api documentation, and it says:

     #include <sys/ioctl.h>

then the user knows that in D he has to do:

     import whatever.sys.ioctl;

What the user should not have to do is:

     version (linux) import whatever.linux.sys.ioctl;
     else version (FreeBSD) import whatever.freebsd.sys.ioctl;
     else version (OSX) import whatever.osx.sys.ioctl;
     ...
     else static assert(0);

nor:

     import whatever.posix.sys.ioctl;
     version (linux) import whatever.linux.sys.ioctl;
     else version (FreeBSD) import whatever.freebsd.sys.ioctl;
     else version (OSX) import whatever.osx.sys.ioctl;
     ...
     else static assert(0);


More information about the Digitalmars-d mailing list