geda-developers team mailing list archive

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

On Sun, 16 Dec 2012 23:44:34 +0000, Peter Clifton <pcjc2@xxxxxxxxx> 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 <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre