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