Re: [Vala] Proposal: CCodeFunc modifier or alike?



On Mon, 2008-05-26 at 11:18 +0200, Juerg Billeter wrote:
On Sat, May 17, 2008 19:54, Yu Feng wrote:
I suggest a new way to specific the way vala mangles the member
functions?

CCodeFunc = cname(paralist);
where cname is the c function's name, and

paralist ::= this | formal param | static members

Several examples to show the flexibility:

class List<weak G> {
    [CCodeFunc this = g_list_insert(this, data)]
    public void insert(G data);
    [CCodeFunc this = g_list_remove(this, data)]
    public void remove(G data);
        [CCodeFunc g_list_free(list)]
    public static void DestroyFunc(List<weak G> list);
}
class List<G> {
    [CCodeFunc this = g_list_insert(this, data)) ]
    public void insert(G #data);
    [CCodeFunc (this = g_list_remove(this, data); G.DestroyFunc(data)) ]
    public void remove(G data);
    [CCodeFunc (g_list_foreach(list, G.DestroyFunc);g_list_free(list))]
        public static void DestroyFunc(List<G> list);
}

It will allow us to pull out a lot of mess from the vala compiler to the
vapi files.

This will also add quite some complexity to the compiler and still have
limits. For example how to handle array length parameters in delegates
with that?
I think it is still possible to use a snippet for delegates with array
length.

They key is to understand if there is a delegate, vala should be able to
generate a wrapper if the callback is different from the delegate, for
both direction.

[CCode cname = "ArrayFormatter"]
[CCode prototype = (
int * (cname)(int * array, int array_length);
)]
[CCode snippet = (
        return = (*cname)(array, array.length);
        return.length = g_strv_length(return);
)]

public static delegate string [] ArrayFormatter(int [] array);


For invocation a Callback, the generated code should be like:

void some_function (SomeType * this, ArrayFormatter formater){
int * array = g_new0(int, 10);
int array_length = 10;
gchar ** formatted_string;
int formatted_string_length;
/*this line is generated according with the wrapper*/
formatted_string = (*formater)(array, array_length);
formatted_string_length = g_strv_length(formatted_string);
}

For passing a vala method to a Callback:

gchar ** my_delegate (int * array, int array_length, int *
return_length);
gchar ** my_delegate_ArrayFormater_wrapper(int * array, int
array_length) {
   int return_length;
/*nothing related to the CCode snippet directive, making use of the
CCode 'prototype' directive. similar to the signal handler wrappers*/
   my_delegate(array, array_length, & return_length);
/*Then the return_length is throw away*/
}
void some_other_function(SomeType * this){
   some_function(this, my_delegate_ArrayFormater_wrapper));
}

In a wrapper snippet, cname, return, return.length, this are predefined
keywords standing for the funcion's cname, return value, and the
returned array's length if it is an array; if the member is not static,
'this' is also available, and all the data member of this which has a
direct mapping to data members of the C structure are accessible by
this.(*) . 

The formal parameters are accessible by referring their names. All the
mangled C functions are available. Also should allow defining local C
variables(but vala shouldn't don't do semantic checking for the c
semantics);

In a 'prototype', parameters are mapped to each other by their names.

It probably makes sense to allow defining small wrapper methods in a .vala
file to be used in addition to the .vapi file, however, we should use
normal method bodies there, this should reduce the complexity.

Yes. When I was thinking of these later, I found actually a CCode
snippet parser has to be written. Troublesome but worthy.

The goal of .vapi files are to regularize the C code into a vala
convention. Thus one can anticipate a lot violations of vala convention
in them. Look at the number of [CCode] modifiers already exists in them
as an example. if one is limited by using normal method bodies, we have
to introduce 'NoArrayLength', 'SimpleType', and such on and on. With the
CCode snippets, all of them are killed immediately.

As an old Chinese saying says, mess get organized after the most
messiness. an extra CCode parser in the ValaCCode namespace will be
where the most messiness stands.

Best,

Yu

Juerg





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]