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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
