RE: TnyAccountTreeModel is now a TnyListIface

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2006-07-06 at 10:57 +0300, Dirk-Jan Binnema nokia com wrote:

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

You are allowed to change the TnyIteratorIface to have a _is_end
property (tny_iterator_iface_is_end). You will have to implement it for
all current iterators (I think there's four or five of them).

That way, your sample pseudo code would work like this:

TnyIteratorIface *iter = tny_list_iface_create_iterator (list);
while (!tny_iterator_iface_is_end (iter))
{
	TnyMyType *instance = tny_iterator_iface_next (iter);
}
g_object_unref (G_OBJECT (iter));

The problem with "is_end", however, is that I only store the "first"
node in the list instances and the "current" in the iterator instances.
Knowing whether there's a next node is simply done by checking whether
current->next isn't NULL.

Checking whether current->next equals g_list_last (first) takes a lot
longer to check. So storing last would be interesting. But when
appending, removing and prepending ... that last would have to be
updated. And that would make appending, prepending and removing slower.
This is something you don't want (for the message header list model,
this would slowdown showing a summary of the headers significantly).

So ... or "is_last" is slow. Or "prepend, append and remove" are.

Luckily you can decide per list which one is going to be slow! ;). And
knowing the last if you once calculated the last, doesn't always have to
be very expensive.

For example when appending, the last is always the new one. When
prepending the last always stays the same. And when removing, you can
check whether you removed the last. And if so, the new last is
last->prev.

So I'm optimistic about the speed YOU will get out if it, Dirk-Jan :D

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

Ok.

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

Indeed, in practice there's not so many. And doing it as GObjects rather
than for example less expensive instances (that can be allocated on the
stack, for example) will help with language binding generators.

But if there's really a compelling reason not to do it as a GObject, I
will (or would). For example, if there's a case where you need
gazillions of iterators (which you don't afaik), it might be interesting
not to do it as a GObject.

But the very idea of the iterator *is* to have one instance of something
per iteration. One such instance takes less then 20 bytes of memory.
Anything under 20,000 such instances isn't worth doing it differently.
The TnyMsgHeader type proved this. But I am thinking about maybe
replacing *that one* with something non-gobject. The amount of
TnyIteratorIface instances you'll typically need isn't anywhere near the
amount of TnyMsgHeader instances ;-).

On average I think there's going to be one, two or three such iterator
instances being active.


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