Re: Introspection API

[Matthias Clasen <mclasen redhat com>]

> On Thu, 2005-02-17 at 17:37 -0500, muppet wrote:
> > Gustavo J. A. M. Carneiro said:
> > > On Tue, 2005-02-15 at 15:38 -0500, Matthias Clasen wrote:
> > >>Does it cover what is needed by language bindings ?
> 
> I probably wouldn't use an interface like this, but rather would
> generate a "static" binding from the XML.  So things like:
> 
> void g_virtual_method_override_class_closure (GType instance_type,
const gchar *name, GClosure *class_closure);
> void g_virtual_method_invoke_base_closure (GType type, const gchar
*name, const GValue *instance_and_params, GValue *return_value);
>
> are more important to Gtk#.  Looks like the interface covers most of
the
> information I would need to generate Gtk#.  

Makes sense. These should be implementable on top of the introspection
api, I think.

> g_param_def should contain information about arrays too, because
> is_pointer doesn't help much in that respect.  For arrays with
> corresponding length params it would be good to be able to identify
> those by more than a shaky n_<name> convention. 

Ok, I probably should have been a bit more verbose about that part
of the proposed api (which was modeled after XPCOM). Here it is again:

/* GTypeDef functions */
gboolean              g_type_def_is_pointer         (GTypeDef
*type_def);
Tag                   g_type_def_get_tag            (GTypeDef
*type_def);
GTypeDef *            g_type_def_get_parameter_type (GTypeDef *type_def,
						     gint      n);
GRegisteredInterface *g_type_def_get_interface      (GTypeDef
*type_def);

Tag would be an enumeration like

typedef enum {
 /* basic types */
 VOID, BOOLEAN, INT8, UINT8, INT16, UINT16, INT32, UINT32, 
 INT64, UINT64, FLOAT, DOUBLE, STRING, GString, 
 /* interface types */
 Interface,
 /* 1-parameter types */
 Array, GList, GSlist,
 /* 2-parameter types */
 GashTable
} TypeTag;

So types like void, void*, uint32, gchar*, etc can all be described
by is_pointer() + the tag. Array types have their own tag, and
get_parameter_type() returns the GTypeDef for the type of the array
elements (similar for lists and slists). For hash tables, there are
two parameter types, one for the keys and one for the values. Types
like GtkWidget* have the Interface tag, and get_interface returns the
metadata for the interface type.

I forgot to include an api for the length parameters, but my draft
spec for the binary metadata already contains the necessary information
for array types:

struct ArrayTypeDescriptor {
  guint   is_pointer :1; /* 1 */
  guint   reserved   :2;
  guint   tag        :5; /* 20 */
  guint   zero_terminated :1;
  guint   has_length      :1;
  guint   length          :6;

  guint16 type;
}

I should probably add some api like

gboolean g_type_def_is_zero_terminated_array (GTypeDef *type_def);
gint     g_type_def_get_array_length_param   (GTypeDef *type_def); 


> > >   Generally looks nice.  But what about callback parameters?
> > 
> > Should be handled by the GFunctionTypeDef corresponding to the
callback's
> > type, if i read the API correctly.
> 

That was indeed my intention.

> Doesn't quite cover it, because callback parameters have scope.  Some
> are call-duration, some are persistent, some are replace-on-next-call,
> some are keep-one-per-2nd-param-value, some are
> removed-by-this-method...

I guess we need to make a little survey of calling conventions and see
how many wierd calling conventions are common enough to include.
Initially
I have included what I found in XPCOM and only added 
caller-owns-container-but-not-contents, since I know we have such 
functions in GLib.


Matthias