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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list