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?
> @@ -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.
> @@ -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 or view it on GitHub:
https://github.com/geany/geany/pull/1465#pullrequestreview-48210361
