Re: [GObjectIntrospection] Cleaning up GIRepository

[Colin Walters <walters verbum org>]

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.

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

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

GIMethodContainer or something?  Sure, would make sense.

> (as a side note: Vala has methods for enums)

Yeah, I may add this but we'll see.

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