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 <[email protected]>
Clifton Electronics
--
Mailing list: https://launchpad.net/~geda-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~geda-developers
More help : https://help.launchpad.net/ListHelp
