Re: [GObjectIntrospection] Cleaning up GIRepository

[Johan Dahlin <johan gnome org>]

[not on gtk-devel, so CC me replies]

On Fri, 20 Aug 2010 01:59:09 Giovanni Campagna <scampa giovanni gmail
com> wrote:
> First of all, sorry if this is not the correct mailing list but I did
> not find a more suited one (and Glib discussion happens here anyway).
>
> I started looking for GObjectIntrospection API recently and I've seen
> a lot of overlap with the original GObject/GType system.
> In particular, I would like to ask why the following were
> reimplemented (using the typelib and not run time type information):

There are three primary reasons for not doing things within the GType system.

A) GLib was up until last year moving very slowly, it seems that multiple year
processes were the norm for even the smallest functional additions.

B) the GIRepsitory API reflects the internals of a binary typelib which will
be loaded from disk via mmap. It's intended to be used by multiple processes
within a gnome desktop and needs to use as little writable memory as possible.
I'm not sure how many bytes that needs to be allocated for a GObject,
but it's in the
multiple 100 byte range, while creating a GIBaseInfo only requires 44
bytes on 32-bit
systems.

C) in many cases we want to avoid using the GType because it is not registered
at that point. Registering the GType means that we have to recursively register
the type and all its parents. Writing a lazy binding for dynamic languages like
python and javascript means that the type registration should only be done
when needed, eg such as when the class wrapper is accessed - usually when
the first instance of specific class is created.

> 1) g_object_info_get_abstract, g_object_info_get_fundamental:
> equivalent informations may be queried from G_TYPE_GET_ABSTRACT,
> G_TYPE_GET_FUNDAMENTAL

See B)

> 2) g_object_info_get_interfaces:
> exists as g_type_get_interfaces + gi_repository_get_from_gtype

See C)

> 3) g_object_info_get_properties:
> transfer could be placed as a GParamFlag and array fixed size / array
> null terminated could be added as part of a new g_param_spec_array()
> (I am not sure about the latter, are there properties which are GArray
> / GPtrArray / C arrays?)
> then is just a matter of g_object_class_list_properties

GObjectInfo needs to know about properties and signals which are also
available in the glib type system because annotations might override them.
For instance, we want to include array/transfer/direction metadata which
is only available in the typelib.

Currently both gjs/pygobject uses the gtype system for both signals
and properties,
but they need to be ported over to use gobject-introspection information.

> 6) g_object_info_get_unref_function & co.
> I see this is to support dynamic GstMiniObject bindings, this is the
> part I understand the least, as it definitely belongs in the type
> system implementation, not type reflection / introspection system.
> I believe bindings, either static or dynamic, should use the
> facilities from GValue and GValueTypeTables.
> This means that objects retrieved from the C API are placed inside a
> GValue with g_value_set_instance.
> Such objects are copied around as GValue, which take care of reffing
> and unreffing.
> The original instance pointer is retrieved for passing to C API
> functions with g_value_peek_pointer.

Registering an unref/ref method requires glib extensions as far as I understand.
The value transformation routines were added since the dynamic bindings for
objects such as GstMiniObject use gst_mini_object_set/get_value

> (By the way, not only GstMiniObject and GObject are GTypeInstance,
> also GParamSpec is, so this writing binding this way could facilitate
> memory management)

GParamSpec is not instantiable, g-i only support GTypeInstances with
the instantiable
flag set. In practice, only GstMiniObject is tested/supported.


> 7) Union, structs, instances all have fields and method. Also,
> instances and interfaces have vfuncs. Finally, GObject / GInterface
> (with a GObject prerequisite) have properties and signals.
> Why each of them has its own method (pun not intended) for introspecting them?
> (as a side note: Vala has methods for enums)

This is because the way the typelib is designed. The data is not
"inherited" properly.
It could be fixed but it would break the typelib compatibility.
I guess patches are welcome to fix that because we freeze the typelib
for GNOME 3.

> 8) On the other hand, all GTypeInstance get a GIObjectInfo, but only
> GObject has properties and signals. Would it be more appropriate to
> move GObject specific code down the hierarchy?

Designed for the GstMiniObject which lacks properties,
would be easy to extend if you had a real-world use case for it.

> Last comment: why none of this API uses GObject and is not even a
> registered boxed?

See B)

-- 
Johan Dahlin