Re: [gtk-list] Gtk--: G_List quirks

[Guillaume Laurent <glaurent worldnet fr>]

Some Guy <guy@mikepery.pr.mcs.net> writes:

> (Tero, this is for you, I just posted here so everyone could have a look)

Actually, I'm the one to blame for this one here. Then again, I acted
on Tero's invitation :-) (*duck*).

[...]

> The problem arises when you are using the G_List::next() and prev()
> functions, thinking they will return a pointer to the next/prev node in
> the list.  However, they don't only do that.  They first modify the glib
> object, then do return this;.  This would work fine for someone doing the
> following:
>    for (list = container->children();
> 	list->glist() != NULL;
> 	list = list->next()) ...

Side note : don't do that. Use iterators :

	list = container->children();
	for(iter = list->begin(); iter != list->end(); ++iter) { ... }

> Then it works as expected.  But what if someone only wanted a temporary
> peek at the next/prev node?  For example:
>    g_print("prev: %s\n", list->prev()->data());

[...]

Yes, you do have a point.

> I think we could solve this problem by just treating GList as a node.  For
> example, redefine the G_List class this way:
> 
> typedef GList G_Node;
> class G_List

[...]

Mm, I'm not too fond of the idea of adding yet another type,
especially if it's only for "hiding" something. I'd rather change the
current API since its far from being cast into stone, and aren't
mapped after any calls from the original GList.

We could either

- add peek_next() and peek_prev() calls which would simply return the
  next/prev node without changing the underlying GList

or

- rename the current next()/prev() to move_next()/move_prev(), and
  have next()/prev() return the node like the peek_* calls.

(new call names are non-contractual :-)

Tero ?

-- 
					Guillaume.
					http://www.worldnet.fr/~glaurent