Re: Proposal for a collection API in glib

[Philip Van Hoof <spam pvanhoof be>]

On Fri, 2008-07-18 at 14:33 +0100, Gustavo J. A. M. Carneiro wrote:
> On Thu, 2008-07-17 at 14:23 -0400, Havoc Pennington wrote:

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

This is indeed to the point. So I'm in agreement with Gustavo.

It *IS* the "C" developer's responsibility to deal with boxing and
unboxing of his arbitrary memory.

Container types that are implemented as a C implementation detail are
also arbitrary memory, just like any other structure that gets allocated
on the heap.

A collection API is a generic way to box C specific collections in such
a way that on top of the boxing, the consumer of it gets a clean API to
use them.

That API is 1-1 with what you are seeing in the more popular higher
programming of today (System.Collections for example in .NET).

Meaning that binding to those languages will be a lot more simple (as
illustrated on the wiki page http://live.gnome.org/IteratorsAPI at the
bottom of the page - for C# -).


With such an API we could also solve the boxing and unboxing of the
elements that are owned by the collection (the things in the sequence).

This way a majority of typing that the language binding developer needs
is solved and/or available for automated code generation.

Anything else on top of that that is needed can be provided by a
library/tool like GObject introspection.

At the same time could GObject introspection serve as a library for
generating collections and iterators that box (that wrap) a known C
container type (like a GList, GPtrArray, GSList, GHashTable) at runtime.


But before you can do that, you need an API. One that also makes sense
for people who don't care about C (at all).


Like how GIO's Stream API makes sense, and how we needed that before we
could start with bridging application's 'stream inventions'.


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be