The CAPI Manifesto

Walter Bright newshound2 at digitalmars.com
Sun Oct 16 21:16:47 PDT 2011


On 10/16/2011 7:18 PM, Ary Manzana wrote:
> So you would put every interface to every possible C code there?

No. It's simply a collection point for interfaces to publicly available C 
libraries. The place to go to see if someone has already written what you're 
looking for. Its mission is also narrowly focused on simply being a way to 
access existing C libraries from D in the most straightforward way possible.


> In Ruby if you want to have very efficient code you'd implement it as C
> extensions. For that, you create wrappers in Ruby for C. Now, big part of the
> standard library has extensions for the most needed things. Everything else,
> like bindings to an efficient xml parser, are made by different people that
> public them as gems. Having a public gem repository it's really easy to find
> bindings for whatever you want. They don't need to be part of the standard
> library. And it wouldn't make sense, having so much functionality out there
> available as C code.

Right.

>
> So I'd suggest having D headers for the most common things in phobos

Yes.

> and focusing on a tool like rubygems. It would give such a big boost to the language.

I think github is adequate for now to be the tool.


> I also can't imagine how that big repository would work. You'd copy the remote
> file locally?

That'll work, or you can use the github 'clone' feature.

> What if that file gets fixes? You'd copy it again? Or maybe you'd
> git checkout everything from that repository locally and synchronize it from
> time to time, with the chance of breaking existing code...
> Having "gems" and versioning them should make all these problems disappear.

Github has extensive versioning and branching support. This shouldn't be an issue.

 > Maybe there is an openssl header in D. The problem is that there might be many,
 > and they don't know each other, and google is a maze to find such things.

Exactly. And maybe there are several openssl D headers, each of which is 
half-assed in a different way. With a central library for them, we can improve 
them globally rather than piecemeal and randomly.


More information about the Digitalmars-d mailing list