Re: [GObjectIntrospection] Cleaning up GIRepository

[Giovanni Campagna <scampa giovanni gmail com>]

Il giorno lun, 23/08/2010 alle 09.10 -0300, Johan Dahlin ha scritto:
> [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.

Well, if so much memory is required for a GObject, then making GObject
more lightweight (possibly without signals and properties) would make
sense.
Secondly, little is gained by sharing the typelib, if the information is
*also* contained in a different private writable memory area.

> 
> 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.

And why you would ever need information about a class which is not used
and/or available to use?

> 
> > 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.

Direction doesn't make sense for properties and I proposed how to encode
array and transfer in GParamFlag.

> 
> 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.

No, the (un)ref method is exposed in the GTypeValueTable.

> The value transformation routines were added since the dynamic bindings for
> objects such as GstMiniObject use gst_mini_object_set/get_value

They should be able to use g_value_set_instance / g_value_peek_pointer,
keeping gst_mini_object_*_value for C convenience.

> 
> > (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.

Ok

> 
> > 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.

Why does the GIRepository API reflect the typelib? The typelib design
should only be an implementation detail of libgirepository, that can be
fixed at any time by recompiling gir files.

> 
> > 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)

Again, I believe you should design the API and the type library
separately, they have different requirements.