Re: [GObjectIntrospection] Cleaning up GIRepository

[Giovanni Campagna <scampa giovanni gmail com>]

Il giorno lun, 23/08/2010 alle 11.54 -0400, Colin Walters ha scritto:
> On Thu, Aug 19, 2010 at 7:59 PM, Giovanni Campagna
> <scampa giovanni gmail com> wrote:
> >
> > I started looking for GObjectIntrospection API recently and I've seen
> > a lot of overlap with the original GObject/GType system.
> 
> Yes.  The answer to most of these questions is that if we could start
> over, GObject would require source scanning, and we'd have a typelib
> by default, and not run-time type registration.  But we have to live
> with the legacy system.
> 
> As to the point about extending GType - that works for things that
> already exist in GType.  But the biggest thing by far is
> functions/methods.  There are smaller things like fields too.

Well, maybe it is time for a GObject 3.0 with built-in introspection and
without the conficling GType features. Then we would have run-time
registered GType for type detection, memory management of classes,
interfaces and instances (as well as automatic value copying and
deleting), that is everything which requires a function pointer, and
GIRepository for meta information about the classes and objects. The
distinction would make sure that libraries don't require -module and
programs don't need -export-dynamic

> 
> > 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.
> 
> A new fundamental type would need to be added I guess.  GCustomObject?
>  Dunno.  It's sort of a hack, really we want GObject to be fast
> enough, and work has gone into that.

Why a new fundamental type? You just need to access the *_ref/*_unref
function pointers, which are exposed in the GTypeValueTable, and if you
don't want to use them explicitly, ref the object by copying a GValue.

[...]

> > Last comment: why none of this API uses GObject and is not even a
> > registered boxed?
> 
> The repository is a GObject.  But I've been trying to move the API
> towards stack allocation for speed. Remember all this stuff happens
> every time a function is invoked, so malloc()ing or even gslice there
> is a notable performance hit (yes, I measured it).

But wouldn't this make it more difficult for introspection based
bindings (like Java) to implement other bindings with introspection
(Rhyno and Jython come to my mind)?