Returning doubly linked lists and other C types

[Philip Van Hoof <spam pvanhoof be>]

Returning C types that are hard to make language bindings for is hereby
forbidden ;-).

I've just removed the last GList* return in the API. All lists are now
being returned as TnyListIface instances or the returns are replaced
with by reference passing a TnyListIface (this is the preferred method).

Walking such lists happens using an iterator. You need to destroy that
iterator when you are done walking. Check the TnyListIface and
TnyIteratorIface API for more information.

Language bindings should attempt to make the TnyListIface and
TnyIteratorIface blend as nice as possible into the existing framework.
For example for .NET, the generated proxy type should implement IList
for the list, and the IEnumeratable (and others) for the iterator.

There's one more major refactor going to happen soon: The
TnyAccountTreeModel is going to implement TnyListIface.

At this moment you have to use the default TnyList type as temporary
store for accounts you'll get from the TnyAccountStore's get_accounts
method. Then you walk that list and add it ti the TnyAccountTreeModel.

Since the TnyAccountTreeModel is also a store with accounts (whether you
see that or you don't, trust me that it *is* such a store), it would be
better if that store would simply implement TnyListIface and that the
store would directly be used by the TnyAccountStore when the
get_accounts fills it. That way there's no more list-copy going to
happen, yet wont the implementer of a TnyAccountStore have to learn
about the internals of the TnyAccountTreeModel (she only has to know
that it implements TnyListIface correctly and that she can use the
TnyListIface API on it).

So this is going to happen. Or if somebody feels brave .. he or she can
join me with the refactor development iteration.

After that .. I think the API will maybe be stable for a few more
weeks ;-). But I will not yet make *any* promises.

Teams interested in building language bindings should definitely contact
me about API stability.


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