Autowrap for .NET is Now Available

[Neia Neutuladh]

On Sat, 15 Dec 2018 00:43:42 +0000, JJS at jjs.com wrote:
>>> Do you have plans to incorportae this as a VisualD project .csproj

Retaining the "On Sat, 15 Dec, Person A wrote:" lines is helpful for 
keeping track of the conversation.

> Using DLangInNet(I'm renamed your project for you ;)

Only the project maintainers have that authority. The project exposes D 
types and functions in Python, Excel, and .NET, so DLangInNet would be a 
terrible name for it.

> You should talk to Rainer about this. It shouldn't be all that difficult
> to do since C#'s PInvoke does all the real work. I assume DLangInNet
> just generates a C# equivalent that forwards all the calls to the D code
> using Pinvoke when necessary?

This is discussed in the Autowrap readme file.

> So the idea is that one can add .d files to .Net projects, when built:

Emitting the C# interface is a separate build target. You need to be able 
to specify Autowrap and the D compiler as dependencies. You need to hook 
this up into the build script.

> 2. DInNet runs on the D code and generates the C# output(could be
> modified for many other lannguages such as python, F#, Haskell, etc).
> Basically an autobinding generator from D to whatever, might be a good
> project to develop.

Perhaps a good name for that would be "Autowrap".

> The point of having it this way in Visual Studio is that one can on a
> single project that has many different languages involved and can setup
> a rather seamless connection.

Add a field to a wrapped D type and it won't show up on the C# side until 
you rebuild. This is not seamless. Making it seamless requires your IDE to 
know how the binding will be constructed and to have good support for 
every language you're using. Plus each language plugin needs to use a 
common set of data structures to represent your source code.

Technically, this isn't hard for a common set of languages, at least if 
you're only binding from a statically typed, strongly typed language with 
ideally little metaprogramming and in any case no ability to change types 
at runtime.

> What we need is an idea that just works and one can use any appropriate
> source language at any time and they all bind without hicup's in most
> cases.

Languages need a certain level of similarity for that to work. Haskell 
assumes immutability and would not work particularly well with a D 
function that mutates its input. Javascript objects can gain and lose 
fields and methods at runtime, something that D can't model well. A Python 
function can return a value of any type at all.