Re: Proposal for a collection API in glib

[Jamie McCracken <jamie mccrack googlemail com>]

On Thu, 2008-07-17 at 13:37 -0400, Havoc Pennington wrote:
> Hi,

> 
> Why explore alternate ideas? Some downsides to GIterator-as-gobject:
> 
> * GObject is pretty heavyweight for something like this, and moreover
> right now libglib doesn't depend on libgobject
> * the need to unref the iterator is onerous for C programmers using iterators
> * the need to subclass a GObject is onerous for C programmers creating iterators
> * as Owen mentioned long ago when this was already discussed, we'd end
> up duplicating bunches of APIs just to make them use iterators instead
> of whatever they use now - this is both bloat and confusing. It would
> not be realistic to ever deprecate walking GList etc. - the iterator
> replacement is much less convenient, and there's way, way, way too
> much code using GList already. You can't deprecate something that
> touches this much code.

As philip's proposal centres around easier bindings this would only
affect public API dealing with licts/collections so all of the above
will probably have negligible impact. 

GList would still be around for internal usage or where performance
matters. The onus would still be on devs to make their api more binding
friendly by using iterators so I feel its important for them to have
that choice

jamie