Re: Proposal for a collection API in glib

["Havoc Pennington" <hp pobox com>]

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

Havoc