Re: [jlbec evilplan org: Enumeration patch]

[Alexander Larsson <alla lysator liu se>]

On Wed, 18 Oct 2000, Joel Becker wrote:

> Everyone,
> 	Ok, I put together a patch to provide opaque enumerations for
> glib.  This is intended to look like java.util.Enumeration, because I've
> found that functionality excellent.  I sent it to Tim, who recommends
> that I get discussion here.

I like this idea. It doesn't solve all problems concerning list-returning
behaviour though. It is still necessary in some cases to know if the
enumerator is a static copy of the container state when it was enumerated,
or if it is using the live state and is invalidated whenever the container
is modified. 

I like it's opaqueness and consistance in usage, it will make it easier
for the user of containers, and it will make it easier to do binary
compatible changes to the internals of thc container.

Some comments on the code:

Why are the g_enumeration_list_* functions in the public API? I can't see
any reason for that.

If the GEnumerationFunc got a pointer to the gpointer context the list
enumerator (and other simple enumerators) won't have to allocate a special
context struct (a list-item in the list-enumerator case). I think that
would make the code simpler.

typedef gpointer (*GEnumerationFunc)	(gpointer *context);

If, in the list-enumerator, you return the current element and then
increment the enumerator you wouldn't have to prepend an empty element to
the list.

> 	Questions, comments, improvements to gtk-devel.  Flames and
> studlyCaps to me privately.

hereAreSomeStudlyCapsForYou.

/ Alex