RE: The iterator interface

[<Dirk-Jan Binnema nokia com>]

Hi Philip, 

>-----Original Message-----
>From: ext Philip Van Hoof [mailto:spam pvanhoof be] 
>Sent: Tuesday, August 08, 2006 17:55
>To: Binnema Dirk-Jan (Nokia-M/Helsinki)
>Cc: tinymail-devel-list gnome org
>Subject: RE: The iterator interface
>
>On Tue, 2006-08-08 at 17:27 +0300, Dirk-Jan Binnema nokia com wrote:
>
>> 
>> >There's one exception, and that is the build-in iterator fot 
>> >TnyHeaderListModel. Adding unreffing and reffing there isn't needed 
>> >as all item-access is locked already anyway.
>> >
>> >And adding the ref and unref would slowdown sorting. That one uses 
>> >'special' _nl functions anyway (so the normal _current 
>implementation 
>> >of that iterator should indeed return with an extra ref, 
>the _nl one 
>> >shouldn't).
>> 
>> Hmmmm... I would say that *all* the _current functions should behave 
>> the same. They're implementing the same interface after all.
>
>Well, the _nl implementations don't really implement the 
>interface. The interface is also implemented by normal 
>implementations. The _nl ones are hacks to make it faster for 
>the internal used iterator. The internal used iterator also 
>isn't really like a normal iterator. 

But I wasn't talking about that; I mean all the implementations of
_current should behave the same. If I understand correctly, 
they don't. All of the ref the return value, except for the one
for the header list.

>These hacks, however, do make sorting significantly faster. 
>Each operation you add to them, will happen a gazillion times. 

Yeah - I am not argueing against that. I just would like to make it
more explicit to the client programmer that the tny-header-iterator
_current behaves very differently from all the others.

My proposal was to either add a boolean flag or make a special
'_unowned', '_floating' version of current that makes this explicit.

>My suggestion :), let the _nl methods or TnyHeaderListIterator 
>and TnyHeaderListModel be what they are. And fix the functions 
>that do implement the TnyListIface and TnyIteratorIface interfaces.

This is what I did in the patch I sent you. I have implemented 
it just as you wanted, and did not include any of my proposals.

>> As the freeing (or not) of returned values is such an 
>error-prone area 
>> anyway, having one of the interface implementations behave different 
>> from all the others is asking for problems.
>
>Right but the interface implementation itself wouldn't behave 
>different.

Or are you saying that the *normal* _current for the header-list iter
_should_ ref, and the _nl version shouldn't? Of course that would be
acceptable too - if properly documented. Then the _nl versions just
take the place of the _unowned I was suggesting.

>> BTW, making these functions void, may help for something 
>else as well 
>> - thread safety; in tny_header_list_iterator:

The patch I sent should fix the thread-safety issues as well.

Best wishes,
Dirk.