I've been working on putting together a list of discrepancies between Vala and GObject Introspection, and I'm not sure which of them are bugs and which are simply irreconcilable differences between the two.
A more complete list is at https://live.gnome.org/Vala/UpstreamGuide (see the "Using Metadata" and "Custom Vala" sections), but some of those are already known to be G-I bugs so I'll omit them (I'm trying to figure out what G-I should support and what it shouldn't, not complain about bugs). 1. Duplicate Symbols Vala has a single scope for methods, virtual methods, signals, and properties, but sometimes their signatures don't match. For example, virtual methods with different arguments from the wrapper function, signals with different arguments from the emitters, etc. We currently try to solve this in Vala by using *.metadata files (a bit like the overrides files for Python or JS) by moving things around or skipping one version. 2. Variadic Functions Vala supports variadic functions, G-I doesn't. The truly frustrating thing here is that GIRs usually include all the information Vala needs, but they add an introspectable="0", which is the same thing a (skip) annotation does, which means we have no way of telling whether the function was only skipped because it is variadic or if there was another reason. 3. Ownership of Struct Fields AFAIK, GObject introspection does not currently offer a way to specify whether or not fields contain an owned reference. It is therefore impossible for Vala to know whether or not it should ref or copy a value being assigned to this field. 4. Virtual Methods Without Invokers Some libraries (like GObject) contain virtual methods without emitters, which GObject introspection does not currently offer a way to annotate (nor does gtk-doc offer a way to document them beyond a basic description). 5. Abstract/Virtual Distinction Vala distinguishes between abstract and virtual methods (virtual methods do not need to be implemented by an class which implements the interface whereas abstract methods do require an implementation) while GIR does not. 6. GClosure Types GIR does not provide a way to annotate the type of a callback contained in a GClosure. There is a bug for this (636812) but it hasn't been confirmed. 7. No Generic Methods There is already a bug (639908) about G-I's lack of support for generic types, but AFAICT nobody has brought up the issue of generic methods such as g_object_get. _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
