Re: Proposal for a collection API in glib

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

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.

Sure, but you are assuming a scenario where g-i already has complete and
accurate metadata about the library APIs.  Assuming that scenario is not
very reallistic, I think.  Most likely what will happen will be that
e.g. the type of GList elements is completely hidden from the header
files, and so g-i's header file scanning tool will not be able to get
such information.  At the end of the day, it will be people doing
language bindings doing the heavy lifting and figuring out, possibly
from the .c files (memory management semantics often are not clearly
documented), and folding back that information into the metadata.  Not
to mention how to merge human provided information with automatically
scanned one.

At leas Philip's iterators would shift some of the burden of making APIs
bindings friendly into the library authors themselves, and contribute
for language bindings to stop being second class citizens, as they are
now.

> 
> >> 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.)
> 
> Havoc
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
"The universe is always one step beyond logic" -- Frank Herbert