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 <[email protected]> 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.
