Custom calling conventions

Gor Gyolchanyan gor.f.gyolchanyan at gmail.com
Tue Feb 21 03:19:26 PST 2012


This is just what I needed. I need to create a new calling convention
to implement dynamic data typing without resorting to incredibly slow
and cumbersome Variant.

On Tue, Feb 21, 2012 at 3:03 PM, Manu <turkeyman at gmail.com> wrote:
> 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! :)
>
> The main benefit over using a template, for
> instance: jniCall!"functionName"(args...), would be the function name is not
> a string, or require custom code construct (facilitating later re-factoring
> or delegation to script without changing masses of existing code, something
> I have done often), and if it was seen by the language as a regular function
> call, you can mark it with all the usual stuff, const/pure/etc, and apply
> the expected set of optimisations to the call.
>
> I'm sure this has been discussed before... so go on, tear it apart :)



-- 
Bye,
Gor Gyolchanyan.


More information about the Digitalmars-d mailing list