On Sunday, 4 June 2017 at 09:43:23 UTC, Adam Wilson wrote:
On 6/4/17 01:18, Jakub Szewczyk wrote:
This is an interface to the Mono libraries, D/CLI would [...]
My interest is less in code ports than bindings to the actual
code. My experience with code ports or translations is that
often subtle bugs creep in during translation due to the fact
that each language has different idioms.
What I am thinking about is a tool that loads an assembly,
examines it's types and methods via this API and emits D code
that directly interfaces into the .NET types via this API. The
tricky part here is mapping the .NET dependencies into D. The
moment the library exposes a type from a dependency, that
dependency ALSO needs to be included somehow. All libraries
reference "mscorlib", AKA the BCL, so we'd have to provide a
"mono-bcl" package on DUB.
That's what I actually meant, "porting" was a misused term on my
part, "binding" would be a better word, sorry for that.
As for the dependency problem - I think that a linking layer
generator would accept a list of input assemblies (and
optionally, specific classes) to which it should generate
bindings, the core Mono types could be automatically translated
to D equivalents, and the rest could be left as an opaque
reference, like MonoObject* in C, also providing support for very
basic reflection through the Mono methods if it turned out to be
useful for anyone.
Mono actually supports some kind of GC bridging as far as I
understand, [...]
On the GC side I was mostly thinking about GC Handles so that
the objects don't get collected out from underneath us. That is
something is trivial to code-gen.
As for exceptions, I like the catch->translate->rethrow
mechanism. And if the exception is unknown we could simply
throw a generic exception. The important thing is to get close
to the D experience, not try to map it perfectly.
Yes, GCHandles to keep Mono objects in D and a wrapper based on
that GC bridge to keep D references from being collected by Mono.
I have previously implemented a very similar mechanism for Lua in
a small wrapper layer, and it worked perfectly.
I can make a static library version, [...]
Thank you for this! I find static libraries easier to deal
with. I'm sure other people have differing opinions, so having
both would make everyone happy.
It's now public as v1.1.0, I've tested that it works with the
tiny sample, the only important part is that the library to link
must be specified by the project using this binding, because
those paths may vary across systems, and they cannot be specified
in code like the dynamic link ones. However, a simple
"libs":["mono-2.0"] entry in dub.json should be enough for most
use cases.
