GNOME Bugzilla – Bug 656499
Static methods for enums/bitfields
Last modified: 2015-02-07 16:54:29 UTC
Changing the scanner to support static methods for enums/bitfields was easy enough, but before I dive into the typelib: is it consensus that static methods for enums/bitfields are desirable? Here's a representative list of changes to the GIR files of glib, atk, gdk-pixbuf and gtk+. Since the patch would use the backcompat machinery also used for class-static methods for boxed, interfaces, etc., the arrows below actually mean 'copy to' so that all the changes would be backwards compatible. - Atk.relation_type_for_name -> Atk.RelationType.for_name - Atk.role_register -> Atk.Role.register - GdkPixbuf.error_quark -> GdkPixbuf.Error.quark - G.dbus_error_encode_gerror -> G.DBusError.encode_gerror - G.dbus_error_new_for_dbus_error -> G.DBusError.new_for_dbus_error - Gtk.icon_size_lookup -> Gtk.IconSize.lookup - Pango.bidi_type_for_unichar -> Pango.BidiType.for_unichar - Pango.script_get_sample_language -> Pango.Script.get_sample_language
Yes, I think this would make us more consistent, and clearly people expect it to work.
Looks good to me as lon as we don't break people already using the old way
I'd like to point out that Vala already does magic when parsing the gir for moving namespace static methods to the relative typesymbol (classes/structs/enums etc.). In particular: 1) We first try to find a proper typesymbol that matches the first parameter of the function. If the method C name matches the class C prefix, then we make the static method an instance method 2) Otherwise we try to find the longest common C prefix with the typesymbols in the namespace Notice that, with regards to bug 572408, the method is being moved, not copied. See http://git.gnome.org/browse/vala/tree/vala/valagirparser.vala#n3124 for reference.
Created attachment 193807 [details] [review] Allow enums and bitfields to have static methods This uses the same backcompat machinery that was introduced for static methods for non-class types, so this change does not break users of the existing presentations.
Review of attachment 193807 [details] [review]: Looks good to me, check with Colin about typelib compat/closer review. ::: girepository/gienuminfo.c @@ +121,3 @@ + */ +gint + * Obtain the number of methods that this enum type has. New api functions need to be added to a file containing list of functions in the docs direcotry ::: girepository/girnode.h @@ +290,2 @@ GList *values; + GList *methods; GSList, as you're never going backwards?
Review of attachment 193807 [details] [review]: Looks good to me.
Thanks for the reviews. Committed with the mentioned changes. Attachment 193807 [details] pushed as 169b206 - Allow enums and bitfields to have static methods
(In reply to comment #5) > ::: girepository/girnode.h > @@ +290,2 @@ > GList *values; > + GList *methods; > > GSList, as you're never going backwards? Sorry, I forgot to reply to this. I used GList simply because all existing nodes use it for lists (and none iterate backwards, as far as I can see). So uniformity suggests GList. Should I change it to GSList regardless?
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]