internal vtable format - name mangling?

Documentation of the current vtable format
---------------------------------------------------------

This is the format that is used to pass interfaces between plugins and 
the core.
The vtable for an interface A is an array of void pointers that is 
terminated by a 0 pointer.
The size of the array is 2 + num_funs(A), where num_funs(A) is the 
number of functions in A
(this includes constructors, the destructor, methods and static functions).

The first pointer of the array is a pointer to a 0 terminated string 
with the interface name.
Then a list of pairs (fun_name, fun_ptr) follows, terminated by a 0 ptr.

So the layout for

interface Blah
{
    void f1() : method;
    int f2(in int x) : method;
}

would be:

   "Blah",
   "f1",
   <ptr to f1>,
   "f2",
   <ptr to f2>,
   0

(Note that the order of the function-name/function-ptr pairs is not 
specified).
All pointers to functions must be pointers to C-functions.



Name Mangling?
----------------------

I'm currently thinking about introducing the signature of the functions 
via name mangling,
s.t. the entry for f2 in the example would be something like
  "method f2 : int -> int" (syntax would be easier to parse for 
computers, though).

This woul allow better checking when loading plugins (you can no longer 
accidentally
call a function with the wrong arguments), and it would allow 
overloading of functions in the
gidl (which is not possible now).

The downside is that we have to make sure contravariance works.
(e.g. in the UnitFactory interface, create() returns Unit, in the 
KalkulonUnitFactory
 create returns KalkulonUnit - this is ok, but we don't have the notion
 of subtypes in gidl so far (i.e. gidlc can't know that KalkulonUnit is 
a subtype
 of Unit)).
But I plan to introduce subtyping to gidl anyhow, so this is not a 
blocking issue.


Georg