Maybe my suggestion is not ideal, since you would still have to do:

  iterator = gst_element_iterate_sink_pads()
  gst_iterator_once_foreach_pad (iterator, callback_func, data);
  gst_iterator_free (iterator);

It's kind of a middle way. The alternative is to add callback-based variants of all the various _iterate*() functions.

OR, and at least from a C language point of view this might be a bit nicer/tighter (since we have no lambda funcs there):

  iterator = gst_element_iterate_sink_pads()
  while ((pad = gst_iterator_iterate_once_get_next_pad (iterator))) {
    do_xyz...
  }
  gst_iterator_free (iterator);

as it seems to me that almost all callback functions are basically 1-3 lines of code anyway.

> It's kind of a middle way. The alternative is to add callback-based variants of
> all the various _iterate*() functions.

Right, I think it is a good option, something like:

Why not just do:

gst_element_iterate_*pads_once (GstElement *element,
    GstPadForeachFunction func, gpointer udata);

gst_bin_iterate_*_once (GstBin *bin,
    GstElementForeachFunction func, gpointer udata);
 
> OR, and at least from a C language point of view this might be a bit
> nicer/tighter (since we have no lambda funcs there):
> 
>   iterator = gst_element_iterate_sink_pads()
>   while ((pad = gst_iterator_iterate_once_get_next_pad (iterator))) {
>     do_xyz...
>   }
>   gst_iterator_free (iterator);
> 
> as it seems to me that almost all callback functions are basically 1-3 lines of
> code anyway.

Could be too.

Another option would be to have a function like that to create a wrapper around the original iterator, then we can use all of the existing functions, a bit like gst_iterator_filter() works:
GstIterator *gst_iterator_once (GstIterator *iter);

I'm not a big fan of having special functions to iterate pads or elements, maybe a generic one for GObjects? Then just have something like gst_iterator_foreach_object()?

I like that idea most! Could be done with gst_value_compare(), which works not only on objects but also integers and other stuff. Not that anybody ever iterates over anything that is not a GObject*, but the GstIterator API allows that.

Tim mostly convinced me that iterators were a terrible API and that having simple foreach function like the one in gst_aggregator, but inside GstElement was the right way to go. I think he has a patch on some bug.

See bug #785679 for Tim's patches

We should simplify GstIterator for 2.0 and get rid of the GValue stuff. Nobody is using it for anything but GObjects, and this is what makes it very hard to use IMHO. It's also not very bindings friendly as-is.

*** This bug has been marked as a duplicate of bug 785679 ***