Re: gobject introspection

[James Henstridge <james jamesh id au>]

Matthias Clasen wrote:

>I have put my prototype for full gobject introspection in cvs now,
>module gobject-introspection. 
>
>But the real reason why I'm posting here is to ask how the different
>language bindings handle unions (in particular GdkEvent). The
>introspection prototype currently doesn't handle unions at all, apart
>from the fact that fields are supposed to have struct offset
>information, so unions could be modeled by describing the overlapping
>fields. CORBA does seem to have a concept of discriminated union,
>which would probably cover the GdkEvent case, but trying to describe
>arbitrary anonymous unions in the middle of structs sounds like adding 
>a lot of complexity. It would be very tempting to just require
>accessors to make those kinds of C-specific things bindable.
>
>So, how do language bindings handle GdkEvent currently ?
>  
>
Not directly related, but here is how pyorbit handles unions (this
matches the standard Python mapping for CORBA):

    * The discriminator is made available as a "_d" attribute (CORBA IDL
      doesn't name the discriminator).
    * The value is exposed as an attribute "_v".  The type of this
      attribute will depend on the value of the discriminator.
    * The values for each branch of the union are named, so an attribute
      is created for each of these values.  Each of these attributes can
      only be get/set if the discriminator has the appropriate value.
    * The in-memory representation of a union in ORBit is just the
      discriminator followed by the value.  So to demarshal the value I
      just move the pointer forward by the size of the discriminator
      (modulo alignment issues), and then demarshal according to the
      type info for the selected union branch.

Assuming we only care about discriminated unions, the form of the
metadata might look something like this:

    * type of the discriminator.
    * offset of the discriminator, relative to the start of the union.
    * a list of names for the different union branches
    * a list of types for the different union branches (indices match
      the above list)
    * a map from discriminator values to union branch indices (ORBit
      does this as a simple array).
    * possibly a default union branch index for the case when no branch
      can be looked up from the discriminator value.

For a case like GdkEvent, the "discriminator offset" would be set to 0,
since the event type is the first member of the union.

For the union inside GtkImage, the discriminator comes before the union,
so the offset would be negative (offsetof(GtkImage, storage_type) -
offsetof(GtkImage, data)).

Does that sound workable?

James.