Custom calling conventions

[Gor Gyolchanyan]

Yes, I;m also talking about compile-time feature. Dynamic typing
certainly doesn't require dynamic calling conventions.

On Tue, Feb 21, 2012 at 3:28 PM, Manu <turkeyman at gmail.com> wrote:
> On 21 February 2012 13:19, Gor Gyolchanyan <gor.f.gyolchanyan at gmail.com>
> 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 <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.
>
>



-- 
Bye,
Gor Gyolchanyan.