Custom calling conventions

[Michel Fortin]

On 2012-02-21 11:03:09 +0000, Manu <turkeyman at gmail.com> said:

> 
> So I was thinking about this extern(language) thing, the obvious ones are
> supported, but it would be really nice to be able to implement custom
> conventions for other languages/scripting languages.
> 
> For instance, I'm thinking about Android, I have JNI binding code
> everywhere, it's really ugly.
> I'd love to be able to declare:
>   extern(Java) int someJavaFunc(int x, float y)
> 
> And then use my function like any regular function, with the 'extern(Java)'
> bit handling the JNI business behind the scenes.
> I also regularly interact with javascript, lua, C#/mono, and these could
> all be implemented the same way.
> 
> I'm imaging some mechanism to declare a calling convention (which would be
> resolved within the extern(...) statement), and define it with a template,
> something like:
> 
> callconv Java
> {
>   R call(T...)
>   {
>     // process tuple of args, make the call, return something?
>   }
> 
>   R thisCall(Class, T...)
>   {
>     // also need a way to implementing methods... this might be enough.
>   }
> }
> 
> Some fancy code in there could conceivably call into any foreign language,
> and this would be great!
> Now when I: import java.jni;
> I have the jni interface, but I also have access to extern(Java), and
> that's awesome! :)

In all currently existing cases, extern(Lang) offers not only a way to 
declare and call foreign-language functions, but also a way to define 
functions to be called from the foreign language. Basically, you have 
two-way compatibility. How would that work with Java?

 - - -

Also, I see you're thinking about methods, which means you're thinking 
about declaring Java classes. How is that supposed to work exactly?

I have some experience bridging Objective-C and D. I once built a 
complete wrapper system for Objective-C objects, each object was 
wrapped by a D one. It worked very well, but it generated so much bloat 
that it became unusable as soon as I started defining enough classes 
for it to be useful. See the D/Objective-C bridge: 
<http://michelf.com/projects/d-objc-bridge/>.

Maybe you'll have more luck, but for me wrappers just couldn't work. So 
I decided making the compiler understand the Objective-C runtime and 
object model was a much better solution. It was fun to do and wasn't 
that hard actually. Here's the result: 
<http://michelf.com/projects/d-objc/>. Unfortunately I don't have much 
time to work on it anymore.

More background:
<http://michelf.com/weblog/2010/dobjc-dead-end-start-anew/>


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/