Re: Call to arms, language bindings

[Philip Van Hoof <spam pvanhoof be>]

On Sun, 2006-08-06 at 23:41 +1000, James "Doc" Livingston wrote:
> On Fri, 2006-08-04 at 10:20 +0200, Philip Van Hoof wrote: 
> > On Fri, 2006-08-04 at 14:56 +1000, James "Doc" Livingston wrote:
> > > * "set Nth item" is impossible as far as I can tell. TnyListIface has
> > > append and prepend, but nothing that can change an item.
> > 
> > You need to use the iterator for this. The list itself doesn't keep a
> > position state. That is what you use an iterator for.
> 
> Make sense. I wasn't really saying that it needed to be a part of the
> list interface, just that (AFAIK) it isn't possible with the current
> API.
> 
> 
> As you mention the obvious thing is for the iterator to have operations
> like "delete" and "set". We would just need to define the semantics of
> those operations, and make the implementations implement them.

Well, deleting and adding/prepending items is for the list type. Not for
the iterator which should only iterate existing lists.

> You mentioned iterator invalidation recently, which is something we'd
> definitely have to sort out.

A possibility would be to register each iterator that gets created in
the list implementations. At this moment none of the list
implementations does this. They would need to unregister themselves when
destroyed of course.

Iterator invalidation is typical by the way. I think most frameworks
that use iterator don't promise the iterator to be valid if the user
changes the content of the list.

There's one exception and that is the internal used iterator in the
TnyHeaderListModel implementation. You can take a look at that one if
you want to implement iterator validity for all lists.

It doesn't have to register because it's a one-one iterator with each
instance of the TnyHeaderListModel type.

> To me, the obvious base semantics would be that the iterator being
> used for modification must remain valid, but all others may (or may
> not) become invalid. Adding a "is valid" operator, and making the
> others return NULL[0] when the iterator is invalid are options.

It's possible to fix the iterator instance if you register it with the
list. So the best solution would be to fix it. Note that fixing this
must be thread-safe. And you can't guarantee that "current" after the
pointer has been delivered to the developer will be correct. 

Unless get_current of the iterator adds a reference. And the API would
be changed to require the developer to unreference it after done. Which
actually is probably the right thing to do. ... 

Hmm .. this might be changed today.

> [0] assuming you aren't allowed to put NULL in iterable things, which I
> haven't checked.

You aren't

> > You can of course create one 'default' iterator per list instance. It's
> > not clean nor the right thing to do. But if that is what it takes to get
> > Python language bindings nice .. I will consider it
> 
> I'm fairly certain that wouldn't help - and even if it did, it could be
> implemented in the Python binding itself.

Ok :)


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