Discrepancies between GObject Introspection and Vala

[Evan Nemerson <evan coeus-group com>]

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.