On Thu, Aug 19, 2010 at 7:59 PM, Giovanni Campagna <scampa.giova...@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). _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list