GNOME Bugzilla – Bug 589331
Generic methods should allow for more flexible bindings
Last modified: 2010-03-21 11:14:46 UTC
There are a lot of methods which currently take a pointer and a DestroyNotify, and it would be very nice to be able to bind them as generic methods, and have the DestroyNotify be set automatically (obviating the need for exposing free methods--see bug #581075). In order to do this I think at least 4 CCode attributes are needed: * Something to hide the GType argument that is currently generated. * Something to hide the GBoxedCopyFunc argument that is currently generated. * Something to mark the position of the DestroyNotify argument (not unlike array_length_pos) * Something to hide / show the DestroyNotify argument (not unlike array_length). It might also be good to have something to mark the position of the GType and GBoxedCopyFunc arguments. It would also be great to have a way to use the metadata files to mark the relevant functions for generated bindings. For a good example of where this would be very useful, please look at Object.set_data_full(), which currenly looks like: public void set_data_full (string key, void* data, DestroyNotify? destroy); But something like this would be much easier to use: public void set_data_full<T> (string key, [CCode (...)] T data);
Confirming
currently (as far as i can tell) the only diference between binding Vala's full-fancy generics constructor style (the one that takes all the extra arguments) and the C-style constructors present in glib (that take no automatic extra arguemnts at all) is the [Compact] attribute on the class itself. it would be better if no assumptions were made on the basis of that and, instead, constructor attributes determined everything (probably very similarly to the way that is suggested in this report).
I've added support for "simple generics" to Vala master using the simple_generics CCode attribute. This made it possible to fix bug 531043. Feel free to reopen the bug if more flexibility is required.