On Sun, 16 Dec 2012 23:44:34 +0000, Peter Clifton <[email protected]> wrote:
> 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. Yes, that's a very good idea. > Also, don't mix _iter and _iterator. I don't think it is required.. pick > one or the other. I vote for iter, on the basis of my fingers. > 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 ()?) Well, GtkTreeModel uses blah_iter_get() IIRC. I'd say you're definitely straying into bikeshed territory with this one! > 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? I think Linus was recently quoted as saying that "dereferencing a pointer is the most expensive thing you can do on a modern CPU", so I would vote for stack. I must confess that I actually really like the GtkTreeIter design. Honestly, though, the most important things to me are that any API we add is simple to understand and use, and future-proof in allowing for thread safety. Peter -- Peter Brett <[email protected]> Remote Sensing Research Group Surrey Space Centre -- Mailing list: https://launchpad.net/~geda-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~geda-developers More help : https://help.launchpad.net/ListHelp
