RE: TnyAccountTreeModel is now a TnyListIface

[Philip Van Hoof <spam pvanhoof be>]

On Wed, 2006-07-05 at 18:20 +0300, Dirk-Jan Binnema nokia com wrote:

> Wouldn't it be more elegant to mimic (say) C++ iterators? Ie.

Depends on your definition of elegant ;-)

> TnyIteratorIface *iter;
> 
> for (iter = tny_list_begin (my_list); iter != tny_list_end (my_list); 
>      iter = tny_list_next (list, iter)) {
> 
> 	MyFoo *foo = MY_FOO (tny_list_item(iter))
> 	/* do something with foo */
> }

In this case, the iter is (like) a token, not an instance that iterates
the list (like an IEnumerator or typical iterator in languages like .NET
and Java). This is very much like the GtkTreeIter which doesn't allow me
to implement per specific list how to travel to the next item in the
list.

Such a custom implementation (that depends on the situation) is
something tinymail in some cases uses.

> As iters are really only pointers somewhere in the list, it shouldn't
> be necessary to explicitely create/unref them (they don't need to be
> full gobjects, which makes 'm faster too).

They aren't just pointers. The iterator might have to implement going to
the next item (which is what happens in tinymail). The implementation
can be different depending on the list (which is the case in some of the
tinymail lists).

The iterator instances are not like the GtkTreeIter (which is more like
what your sample does, and probably like the C++ iter). 

> I'll look into the implementation tomorrow....

It's current design is like this one:

http://www.dofactory.com/Patterns/PatternIterator.aspx

It shows how the list has a "CreateIterator" method that will return a
concrete iterator. This is exactly what the tinymail lists also do.

The reason why you don't have to destroy these instances in languages
like Java and .NET, is simply because you have garbage collectors. We
don't have that in C/GObject (by default), so you'll have to destroy the
instances.

If you have your TnyIteratorIface in the heap, like in your sample, it
wouldn't be possible to make your sample thread-safe, unless it's a new
allocation (thus a new object each time you'll iterate). But that means
that you need to destroy it.

The iterator in GtkTreeView/GtkTreeModel, GtkTreeIter is typically
allocated on the stack and for each iteration you are going to perform.
It will therefore get destroyed automatically when the stack frame ends.
I'm guessing the same thing happens with the C++ iterators and/or maybe
in C++ smartpointers are used for the iterator destruction.


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be