After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 589331 - Generic methods should allow for more flexible bindings
Generic methods should allow for more flexible bindings
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Methods
0.7.x
Other Linux
: Normal normal
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks: 531043 581075
 
 
Reported: 2009-07-22 08:41 UTC by Evan Nemerson
Modified: 2010-03-21 11:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Evan Nemerson 2009-07-22 08:41:26 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);
Comment 1 Jaap A. Haitsma 2009-07-26 10:26:57 UTC
Confirming
Comment 2 Allison Karlitskaya (desrt) 2009-09-03 18:01:37 UTC
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).
Comment 3 Jürg Billeter 2010-03-21 11:14:46 UTC
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.