RE: TnyAccountTreeModel is now a TnyListIface

[<Dirk-Jan Binnema nokia com>]

Hi Philip, 

>-----Original Message-----
>From: ext Philip Van Hoof [mailto:spam pvanhoof be] 
>Sent: Wednesday, July 05, 2006 18:56
>To: Binnema Dirk-Jan (Nokia-M/Helsinki)
>Cc: tinymail-devel-list gnome org
>Subject: RE: TnyAccountTreeModel is now a TnyListIface
>
>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.

Well, C++ iterators are specific for the container type; they
just implement the same interface. The iterator for a std::vector
is different from a std::dequeue. They are created on the
stack (not heap).

I don't really see why I couldn't lock the list above; I
might even have const_iterator, and I'd only need to write-lock
the list.

>> 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).

I meant pointers in the generic "something that points to something
else"-sense.

>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

Urgh. The problem with that one is the weird code one has to write
with HasFirst, HasNext etc. That was my problem with it.

I was thinking about something along the lines of:

IterIface *iter = (Iter*) list_begin (mylist);
while (!(list_is_end_iterator(mylist, iter)) {
	
      Item* item = (Item*)iter_item (iter);
      /* do something with item */
	
	iter_iface_next (iter);
}
g_object_unref (G_OBJECT(iter));

(Admittedly, I am bit std::-biased)

So, 'begin' gives you the first item; 'end' is the position
just 'on the right side' of the last item, ie. outside the list.
If the list is emtpy, the iterator will point to that position.

Doing it like this, we don't need the special casing, IsFirst,
HasNext etc., that I did not like about the current API.

Any thread-safety concerns are just like they are in the current
API. One could question whether we really need full GObjects
for the iterators; but in practice, there are probably not so
many. The heap-vs-stack issue was not really the point of my
post, I was just concerned about the API.

Best wishes,
Dirk.