[Vala] Alternative vapi wrapping model

[Sam Liddicott <sam liddicott com>]

My previous model for allowing vapi wrapped classes to have virtual
methods involved block the object model at the vapi interface; i.e.
gobject stuff can traverse superclasses and so forth until they reach
the first vapi class, at which point class metadata is not available,
although virtual methods and protected methods and properties still work.

I have a new idea which will permit proper gobject behaviour all the way
up to the top, and even allow one vapi-wrapped struct to nicely subclass
another.


The difference in this suggestion is that gobject users don't have to be
aware of the actual storage locations of the vapi-wrapped members, they
only have to be aware to de-reference the pointers. Perhaps this will
make things simpler for things that script gobjects.

The gobject style class definition (which is a nested definition of
structs) is used as normal, except that for vapi structs wrapped as
classes, the class definition is a pointer to each member rather than
the literal members themselves.

e.g. if this were the wrapped struct:

struct verbalizer_module_context {
        struct verbalizer_module_context *prev, *next;
        struct verbalizer_context *ctx;
        int depth;
        const struct verbalizer_ops *ops;
        void *private_data;
};

and this the vapi:

namespace Api {
    public class Verbalizer {
       public int depth;
       public int thing(int x);
    }
}

then this would be the style of the generated class definition:

struct _Verbalizer {
    GTypeClass parent_class;
    struct verbalizer_module_context *_SHADOW;
    int *depth;
    gint (**thing) (Azig* self, gint x);
};

There is a _SHADOW member which points to the actual wrapped struct,
which complements the private_data member which points back to the
actual object instance

Each other member of the gobject instance struct is a pointer to the
actual location in the wrapped struct; thus all gobject users need to do
is remember that for VAPI-level superclasses or above
1. to implicitly de-reference the pointers
2. use the _SHADOW member when typecasting to a superclass to call
methods of the superclass or functions that take a superclass as a
parameter.

Vala functions or methods that take a superclass as a parameter or
override methods that take a superclass as a parameter must (as
mentioned before) still use a macro to use the CCode hinted expression
to convert from the wrapped struct verbalizer_module_context into the
subclass instance; in this case ->private_data.

Sam