Created attachment 119024 [details] [review]
remove "this" parameter for methods

There's plenty of re(In reply to comment #0)
> Hi, I was looking at adding the "this" to signal GIR, but really I don't see
> the use - it seems redundant and makes more sense to instead remove it from
> methods.

There's plenty of redundant information in the GIR available today.
I looked into removing the this parameter earlier, but I decided against it since it was actually making the bindings harder to write in pybank.

I'm not against removing it per see, I just know that it'll make some bindings harder and others easier.

I'll be on the hook to make the corresponding changes for girepository/pybank.  

Created attachment 119450 [details] [review]
update to make g_function_info_invoke work

Created attachment 119451 [details] [review]
patch for pybank

After making this patch I'm increasingly feeling it makes sense to remove g_function_info_invoke and have pybank do the invocations directly.  There's a lot of overhead in the current approach, and it will just be easier to handle the logic entirely inside pybank when we want to do more complex things like the array+length handling etc.

Comment on attachment 119450 [details] [review]
update to make g_function_info_invoke work

Unrelated thing I noticed, this would be a good place to use g_alloca:
  atypes = g_new (ffi_type*, n_invoke_args);
  args =  g_new (gpointer, n_invoke_args);

I don't think this error is clear if someone isn't looking at the source for the function:
+		       "Too few \"in\" arguments (handling this)");

Maybe "Invoking a method, no args were passed in, at least a 'this' arg is required" or something.

For all the "too few args" messages, including the expected number would be helpful.

Patch seems like a good idea to me overall.

Havoc: compare with bug 401080, the code there is similar and uses g_alloca as well.

(In reply to comment #5)
> Created an attachment (id=119451) [edit]
> patch for pybank
> 
> After making this patch I'm increasingly feeling it makes sense to remove
> g_function_info_invoke and have pybank do the invocations directly.  There's a
> lot of overhead in the current approach, and it will just be easier to handle
> the logic entirely inside pybank when we want to do more complex things like
> the array+length handling etc.

Looks good, and I agree that generally it'll be a good idea to let pybank do the complete invocation itself and convert between PyTypeObject and ffi types directly.

Ok, merged.  I updated the patch to use g_alloca similar to bug 401080.

r647 = 589426a456c52eafbb8a52ff02a27e5435d183d9 (git-svn)
r648 = c030fed7c1e46efe304d83740c5d8f15e9785859 (git-svn)
r649 = 27c84d4fb215dd17de91cd11c3be2d0ff32801c3 (git-svn)

[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]