GNOME Bugzilla – Bug 572415
Have glib:ref-function, glib:unref-function, glib:copy-function and glib:free-function attributes where appropriate
Last modified: 2018-02-08 11:49:13 UTC
There is gir annotation for: - ref and unref function for classes - copy and free function for structs These informations are mandatory for bindings to behave appropriately.
GBoxed has copy and free for structures (well, it's not strictly speaking right to use GBoxed for this, but it works OK in practice). ref/unref for classes sounds like the "non-GObject class" problem, which is definitely trickier than just ref/unref functions. Right now <class> means GObject. If we want to accomodate other things (and I'm not opposed to that) it needs toplevel design discussion first.
Not all structures are GBoxed registered, so we probably still need such attributes, although the `c' namespace might make more sense. We definitively need more than just ref/unref for non-GObject classes. I'll try to come up with a proposal.
Ok, let's make this bug about ref/unref/free for structures, the classes should be a separate bug. How should we determine ref/unref/free? Automatically from the name (look for _ref at the end)? An annotation?
automatic would be nice. it seems like the "generic annotations" support in bug 571548 would let you specify them beyond that, assuming that the namespaces got mapped right...
Yeah, we can probably pretty safely assume that a function ending in _ref on a C struct is a ref function, though we may need an annotation to override that. Like my comment on the non-GObject classes, the main question here is what impact struct refs has on bindings. Right now introspection and most implemented bindings are based on a GObject world. I'm assuming bindings would need to respect (transfer) for refcounted structures? What is the default for (transfer) and ref-structs? We need to look at some cases/sample code and see how this would be used.
This affects for example GLib.MainLoop, which is unusable with current gobject-introspection HEAD. Its constructor (g_main_loop_new) is marked as `introspectible="0"', since it returns a pointer to a non-boxable record type. Several other types in GLib are affected as well (e.g. GIOChannel). I'm not clear on how this should be resolved; do we need to add extra fields (ref_func, unref_func) to StructBlob and UnionBlob?
(In reply to comment #6) > I'm not clear on how this should be resolved; do we need to add extra > fields (ref_func, unref_func) to StructBlob and UnionBlob? I'd vote for 'structs can be used by introspection only when boxed' approach, as it is in current gobject-introspection HEAD. This not only solves ref/unref functions problem, but also assigns typeid so it makes bindings implementation easier when checking types when passing them to called functions. I'm not sure how realistic is the requirement to have all introspectable structures boxed, though. Would there be any opposition in GLib to add G_DEFINE_BOXED for GMainLoop, GTimer, GIOChannel, GChecksum, GDir, GKeyFile, GMappedFile, GRegex etc... ?
(In reply to comment #7) > > I'm not sure how realistic is the requirement to have all introspectable > structures boxed, though. Would there be any opposition in GLib to add > G_DEFINE_BOXED for GMainLoop, GTimer, GIOChannel, GChecksum, GDir, GKeyFile, > GMappedFile, GRegex etc... ? > Is this even possible for GLib? I think boxing is a feature of the GObject library, hence unavailable in GLib. If I'm not off track here, we really need this feature, or GLib will not be bindable.
(In reply to comment #8) > (In reply to comment #7) > > > > I'm not sure how realistic is the requirement to have all introspectable > > structures boxed, though. Would there be any opposition in GLib to add > > G_DEFINE_BOXED for GMainLoop, GTimer, GIOChannel, GChecksum, GDir, GKeyFile, > > GMappedFile, GRegex etc... ? > > > Is this even possible for GLib? I think boxing is a feature of the > GObject library, hence unavailable in GLib. If I'm not off track here, > we really need this feature, or GLib will not be bindable. Ouch. That's right. Maybe GObject library could provide boxing for GLib types (in the same way as GObjectIntrospection provides typelibs for GLib/GObject/etc.) But you are right, this makes my proposed solution even less atractive :-(
GObject already registers a bunch of boxed types: http://git.gnome.org/browse/glib/tree/gobject/gboxed.c?id=e35ed21f43f94443e5b137d85120b87542261c5b#n123 It makes sense to register the remaining types in glib there, as long as the boxed semantics are suitable for these objects.
(In reply to comment #10) AFAIK GMainLoop has ref/unref methods, so boxing it should be without problems. But the problem is that g-ir-scanner does not currently pick these up, most probably because structs are defined in GLib namespace, while appropriate _get_type() methods are in GObject namespace.
Created attachment 169674 [details] [review] Makes GMainLoop boxed as many similar GLib types already are Prerequisite for the next patch.
Created attachment 169675 [details] [review] GLib.gir and typelib taught about GLib structs boxed by libgobject Experimental patch, takes into account that many GLib structs have boxes defined by libgobject (mostly in gboxed.c). This makes these structures much more accessible from typelibs, e.g. it allows using GMainLoop.new() as requested in comment #6.
Created attachment 169691 [details] [review] Make MainLoop and related structures boxed. Make boxed also GMainContext and GSource.
I've been saying so far that both GLib and GObject are in "may require manual binding" mode, so it's not a bug in GLib that GMainLoop isn't introspectable. In this specific case, it probably does make sense to box GMainLoop in GObject though.
Created attachment 169764 [details] [review] Make more GLib structures boxed by libgobject.
Created attachment 169765 [details] [review] Recognize GLib structures boxed by libgobject.
(In reply to comment #15) > I've been saying so far that both GLib and GObject are in "may require manual > binding" mode, so it's not a bug in GLib that GMainLoop isn't introspectable. > > In this specific case, it probably does make sense to box GMainLoop in GObject > though. I agree with this sentiment. There's no need that every single structure that occurs in glib headers needs to be introspectable. E.g. GIOChannel has been pretty much superseded by gio facilities.
(In reply to comment #18) > There's no need that every single structure that occurs in glib headers needs > to be introspectable. E.g. GIOChannel has been pretty much superseded by gio > facilities. Ok, understood. > > In this specific case, it probably does make sense to box GMainLoop in GObject > > though. But what about GMainLoop/GMainContext? AFAIK these are not superseded by anything else, yet very useful/vital even for higher-language usage/bindings.
(In reply to comment #18) > (In reply to comment #15) > > I've been saying so far that both GLib and GObject are in "may require manual > > binding" mode, so it's not a bug in GLib that GMainLoop isn't introspectable. > > I see where you are coming from, but GMainLoop and GIOChannel were introspected and usable with previous versions of gobject-introspection, so I consider this a regression. > > In this specific case, it probably does make sense to box GMainLoop in GObject > > though. > > I agree with this sentiment. > > There's no need that every single structure that occurs in glib headers needs > to be introspectable. E.g. GIOChannel has been pretty much superseded by gio > facilities. It has, but unfortunatly GIO does not provide all functionality GIOChannel provides. For instance, it seems not possible to be just notified (without reading anything) when some GInputStream becomes readable -- this functionality is provided by g_io_add_watch(), but there seems to be no equivalent functionality in GIO. Given that making GIOChannel and the other currently non-introspectable types work again just requires adding a few boxed types to gobject, I don't see a reason why this cannot (or should not) be done.
(In reply to comment #20) > It has, but unfortunatly GIO does not provide all functionality > GIOChannel provides. For instance, it seems not possible to be just > notified (without reading anything) when some GInputStream becomes > readable -- this functionality is provided by g_io_add_watch(), but > there seems to be no equivalent functionality in GIO. > > Given that making GIOChannel and the other currently > non-introspectable types work again just requires adding a few boxed > types to gobject, I don't see a reason why this cannot (or should not) > be done. Actually GIOChannel *is* already boxed by gobject, the problem is that it is not picked up by g-ir-scanner; see my 2nd patch attached to this bug (you'd have to modify it to include only types already boxed by gobject, not the ones boxed by the 1st patch), but I'm not sure if GI maintainers would like this solution ;-)
So, to revive this. It looks like these two patches were the resolution for missing introspectable types in GLib. However, back to the thesis of the bug. Was g-i updated to allow annotation of copy/free functions for structs (without the struct having to be G_DEFINE_BOXED)?
Just a note that GMainLoop&co were recently made boxed, and picked up so by GI. See bug 657725
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/14.