Re: Proposal for a collection API in glib

[Yu Feng <rainwoodman gmail com>]

On Thu, 2008-07-17 at 14:23 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Thu, Jul 17, 2008 at 2:06 PM, Philip Van Hoof <spam pvanhoof be> wrote:
> > You could make a GLib.Iterator that uses gobject-introspection, but I
> > don't think you want to make gobject-introspection the one thing
> > everybody who wants to expose collections in his API has to use and
> > learn.
> 
> I didn't mean that - I meant if you exposed collections you'd use
> GList or whatever, and g-i would know that it was a "GList of Foo",
> and g-i would generate an iterator around the list based on that. Then
> users of the g-i API for language bindings would see only the
> iterator.
> 
> >> Any language binding not using g-i has nothing to stand on if they
> >> whine about manual work - they need to a) port to / help with g-i and
> >> then b) we'll talk.
> >
> > Disagree with this. GObject-introspection can be an aid for the many
> > quirks and Cisms our platform introduces. Future APIs should not focus
> > on just the C application developers.
> 
> g-i is not for C afaik. It's supposed to replace all the
> source-code-scanners and "defs" files and so forth different language
> bindings are using. It should be extended until it completely replaces
> those things.
> 
> g-i allows dropping static stubs - all functions are invoked *through*
> g-i, and return values are marshaled with it also.
> 
> > It'll also be useful for other tasks that right now require scripts to
> > parse C code, as gobject-introspection will ship with a bunch of very
> > interesting tools for that (representing an existing API as an XML that
> > will be suitable to throw at a XSL compiler).
> 
> Ideally all scanning (and merging in lookaside info) will happen in
> g-i, which will then have everything a binding needs in the binary
> typelib.
> 
> > If GLib library authors wont focus on higher programming languages, then
> > I fear Gtk+ and its accompanying large set of excellent libraries will
> > get more and more neglected. But that's just my personal feeling.
> 
> We don't need to break C to support other languages. Most libs will
> keep being written in C, and lots of existing useful code is in C, so
> we should keep having good C support.
> 
> I think the ideal situation for the desktop looks a lot like Firefox
> or Emacs or World of Warcraft for that matter, with a C/C++ core and
> the top layers (including most visible functionality) in an agile
> language. Well OK, if starting 100% from scratch, it might be more
> ideal to write everything to a single virtual machine - but we aren't
> starting from scratch, we're starting with millions of lines of
> existing useful C code.
> 
> > I don't know why only C/GLib experts should be the ones writing language
> > bindings (which is the case right now). It's quite hard to find people
> > who are into the higher language and yet know really a lot about GLib
> > too. Usually these people have no reason whatsoever to care about GLib
> > and its isms anymore.
> 
> g-i should be able to include any code that is generic across all bindings.
> 
> >> * as Owen mentioned long ago when this was already discussed, we'd end
> >> up duplicating bunches of APIs just to make them use iterators instead
> >> of whatever they use now - this is both bloat and confusing. It would
> >> not be realistic to ever deprecate walking GList etc. - the iterator
> >> replacement is much less convenient, and there's way, way, way too
> >> much code using GList already. You can't deprecate something that
> >> touches this much code.
> >
> > I didn't mention deprecating this code ...
> 
> The point is that if we don't deprecate GList, as I think we can't,
> then we end up with duplication and bloat. (Two versions of all
> existing APIs, at minimum.)

What about keep using GList in the inside; and always use collection API
when the functions are to be invoked by bindings?

GList's api is really convenient and light for managing weak references.
GHashTable has some ability to manage strong reference but it surely
know little about the GType of the object it holds.

anyway I think GList and GHashTable is enough in doing their job; but
they are a nightmare when binding to other languages. I really hate
those special code in vala in keeping track of the strong references.

BTW: I think it is a good chance to discuss this since people are also
deciding the GTK 3.0 APIs now.

Yu

> 
> Havoc
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list