geda-developers team mailing list archive

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Sun, 2012-12-16 at 22:59 +0100, Ivan Stankovic wrote:

> As for the API, how about this:
> 
>         EdaObject *obj;
>         EdaObjectSetIterator *it = eda_object_set_get_iter(objects);
> 
>         while(eda_object_set_iterator_valid(it)) {
>                 obj = eda_object_set_iterator_get(it);
>                 it = eda_object_set_iterator_next(it);
>         }
> 
>         eda_object_set_iterator_destroy(it);
> 
> This is similar to iterator APIs in Pango, GTK+ etc.

Nitpicking bike-shed coloring point, can we avoid the string _set_ in
any API which is not a property setter please.

Perhaps we could define the noun "objectset" to avoid confusion, and
reserve _set_ as a verb.

Also, don't mix _iter and _iterator. I don't think it is required.. pick
one or the other.

eda_objectset_get_iter

eda_objectset_iter_is_valid  <--- Note I added the _is_, although GLib
can't seem to make up its mind whether it should use _is_valid or _valid

eda_objectset_iter_get       <--- Hmm.. confusing with the 1st one,
should it be eda_objectset_iter_get_data or eda_objectset_iter_data,
similar to GList's APIs such as g_list_nth_data ()?)

eda_objectset_iter_next

eda_object_set_iter_destroy  Most GLib iter APIs use _new and _free for
lifecycle management. I'm assuming our iters are going to be heap / pool
allocated, not typically stack variables like the gtk_tree_* functions.

(Note that the gtk_tree_* iterator functions typically take the address
of an iter structure allocated on the function's local stack. There are
dynamic verisons, such as  gtk_tree_iter_copy() and gtk_tree_iter_free
() designed for use by language bindings which require that.


Does anyone know if the gtk_tree_* approach is better / more optimizable
because the iterator is usually on the stack?


-- 
Peter Clifton <peter.clifton@xxxxxxxxxxxxxxxxxxxxxxxxx>

Clifton Electronics