Proposal for a collection API in glib

[Havoc Pennington-2]

Hi,

On Sun, Jul 20, 2008 at 4:21 AM, Colin Walters <walters@...> wrote:
> Again I think the point is we want to move this burden to the library
> authors (supported by the authors of all language bindings), rather than
> redundantly duplicating it in each binding.
>

Yes, in the short term the gir-repository module acts as a common
repository where only one binding author has to submit the memory
management annotation, and then all bindings have it. In the slightly
longer term (when gobject-introspection is "1.0") the gir should move
into each upstream package instead.

It's a good goal that failure to specify memory management should
break the build, I don't know if it would now; there might be a
default right now. I think a default for that might be bad.

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

[Steve Frécinaux]

> On http://live.gnome.org/MikkelKamstrup/GCollection you will now find
> a sample patch against trunk (rev 5882) implementing GIterable as
> described on the page.

I don't understand why the GType appears in the function call for
g_iter_next(). As I understand it, a GIter will always be used to
iterate on a single object, thus the GType should be a struct member
of its.

Thus you'd have something like the GtkTreeIter:

GIter foo;
foobar_get_iter (foo);
while (g_iter_has_next (foo)) {
  gpointer elt = g_iter_next (foo);
  ...
}
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Mikkel Kamstrup Erlandsen-2]

2008/7/21 Steve Frécinaux <nudrema@...>:

>> On http://live.gnome.org/MikkelKamstrup/GCollection you will now find
>> a sample patch against trunk (rev 5882) implementing GIterable as
>> described on the page.
>
> I don't understand why the GType appears in the function call for
> g_iter_next(). As I understand it, a GIter will always be used to
> iterate on a single object, thus the GType should be a struct member
> of its.
>
> Thus you'd have something like the GtkTreeIter:
>
> GIter foo;
> foobar_get_iter (foo);
> while (g_iter_has_next (foo)) {
>  gpointer elt = g_iter_next (foo);
>  ...
> }

Right. It is not obvious why I need the GType argument, but there is a
reason for it (although whether or not it is the right thing to do can
certainly be discussed):

Obviously the GType argument is used to look up the the right vtable
for the iterable. My idea was to _not_ require a g_iter_init()-like
call, but be able to use the GIter directly with out initialization
(and have that done automagically inside iter_next() and
iter_has_next()), so one could just do:

GIter iter = {0,};

while (g_iter_has_next (type,& iter, iterable)) {
    g_printf ("%s\n", g_iter_next(type, &iter, iterable));
}

With a g_iter_init (GType type, GIter *iter, gpointer iterable) we
could strip the 'type' and 'iterable' arguments from the
g_iter_{has,}next() methods though, so the price I pay is quite high.
Perhaps too high.

The idea of using the (Gtype, GIter, gpointer) signature was also to
keep it aligned with GBoxed. If we move away from this it might be
better to simply use GType interfaces (without full GObjects (as I
also discussed with Jurg on IRC)).

Cheers,
Mikkel
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Philip Van Hoof]

So,

Do we have a conclusion on this proposal?


On Thu, 2008-07-17 at 17:51 +0200, Philip Van Hoof wrote:

> Hi there,
>
> I would like to propose this API to go into glib/gio:
>
> http://live.gnome.org/IteratorsAPI
>
> A working implementation of it can be found here (just replace Gee.List
> with GLib.Seq, as that is the name that we have for it in mind):
>
> http://svn.gnome.org/viewvc/libgee/trunk/gee/
>
> To see users of this API, take a look at for example the Vala project.
> On the IteratorsAPI wiki page, at the bottom, there are also a lot of
> examples of projects that are right now inventing their own collections.
>
> We are working on adding convenience functions for C to make things as
> type safe as possible (the #1 problem with glib's current collection
> types):
>
> gchar*  g_iterator_get_as_string (GIterator *iter);
> gdouble g_iterator_get_as_double (GIterator *iter);
>
> A normal use-case would be a GObject in a sequence, which would with the
> caller-owns API 'g_iterator_get' mean that you need to unref what you
> get. We are thinking about making it possible to pass a 'free-function'
> to the owner of the items (the collection), and to allow annotating how
> to free what you get from 'g_iterator_get' (as it's caller owns).
>
> Right now, with the usage of GHashTable, GPtrArray and GList, language
> binding developers loose all meaningful type information.
>
> This means that they have to resort to using manually written glue code.
> This is among the reasons that makes fully automated language binding
> generation a nearly impossible task at this moment.
>
> In my opinion it's one of the reasons why we never really achieved
> topnotch compelling language bindings, even though that was the #1
> promise of Gtk+ back when it all started.
>
> It's of course debatable whether or not they topnotch. They are not for
> me and having a collection API that actually does make sense outside of
> the C world would in my opinion be one more step in the direct direction
> of improving this situation.
>
> This of course doesn't "magically" fix existing Cism APIs. But take a
> look at the wiki page mentioned above for example on how this can easily
> be improved.
>
>
> Thanks, and please don't troll about how great doubly linked lists are.
>
> It's not the point.
>
>

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