@b4n commented on this pull request.

This looks good, and useful. However, which impact does it have on performance for dynamic languages which would likely always ref/unref through the GBoxed API, even when not actually needed. Or are Python and other GType bridges smarter than that and only copying when really required?

In src/tagmanager/tm_tag.c:

> @@ -82,7 +82,11 @@ typedef struct
 	gboolean first;
 } TMSortOptions;
 
-/* Gets the GType for a TMTag */
+/** Gets the GBoxed-derived GType for a TMTag.

Should we advertise it's derived from GBoxed? C code should probably have access to tm_tag_ref()/tm_tag_unref() instead as it has more meaningful semantics as g_boxed_copy(), and generic code can figure it out by itself looking at the type information.
And advertising GBoxed means it's kind of stuck to that implementation -- which is likely to say indeed, so I'm probably nitpicking, but we could want to change that one day.

Anyway, that's not a so important point.

In src/tagmanager/tm_tag.c:

> @@ -82,7 +82,11 @@ typedef struct
 	gboolean first;
 } TMSortOptions;
 
-/* Gets the GType for a TMTag */
+/** Gets the GBoxed-derived GType for a TMTag.
+ *
+ * @return TMTag type
+ * @since 1.31 (API 232) */

unfortunately that probably will have to be updated

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.