DStep - Bindings Generator 0.0.1

[Andrej Mitrovic]

On 7/7/12, Walter Bright <newshound2 at digitalmars.com> wrote:
> so you could do things like:
>
>      import "stdio.h";
>
> and the D compile would fork/exec Dstep, generate the corresponding .d file,
> and
> import the .d file.

Personally I think this is heading in the wrong direction. A D user
shouldn't have to deal with C syntax or peculiarities of wrapper
libraries, the experience of using a wrapper library should be as
transparent as possible. Such a wrapper library should look just like
any other D library to the user. Wrapper maintainers can use tools to
generate bindings, and the users might have their own tools such as a
package manager to make discovery & installation of those libraries
easy.

There's compile-time performance issues to consider. Sure, you could
cache the results of generating a library, but this is still a penalty
because every user will have to wait for that import statement to
finish the first time and cache the results before they can use the
library, as opposed to the traditional way of downloading a maintained
wrapper library which you don't have to re-wrap but just need to
compile.

I don't mean to sound discouraging, and this all might work for simple
C libraries and Dstep, but there's a penalty for introducing special
syntax and semantics into D for something that can be and is usually
done externally by wrapper maintainers (think how we're always trying
to move things away from the D language and replace it with more
flexible and more easily debuggable library features).

Maybe this feature would look great in a D vs Go comparison table, but
I don't see the benefit of such a magical feature. I'd rather we have
a package manager instead, which incidentally again Jacob is working
on. Incidentally I'm also working on my own wrapper generator,
although this one handles C and C++. But it won't be done soon (it's
close though).