On 21 February 2012 13:19, Gor Gyolchanyan <[email protected]>wrote:
> 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. > Umm, I am of course talking about a compile-time feature. I believe you'd have to use some sort of variant behind there if you wanted to make dynamically typed calls... 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. >
