On Wed, Jul 14, 2010 at 9:01 AM, Maciej Piechotka <[email protected]> wrote: > On 13/07/10 17:23, Didier 'Ptitjes' wrote: >> All in all, breaking the ABI/API is not a problem, as we still have at >> least one anticipated round of developement where we do expect to break >> the ABI. So don't let that limit your imagination/creativity/engineering... > > I've done some thinking and I'm somehow unhappy about current > Iterator<G> design (I was discussing it before but it wasn't so big > problem as it was on iterator-as-primary-thing-we-operate-on). I know > that would be a big change in interface so it may be something we should > be really careful.
Here's another idea, that will preserve the "collection as atomic unit" behaviour, but avoid creation of multiple temp arrays: We could divide the enumerable methods into two classes, "lenses", that layer a lazy transformation over a collection, and evaluators, that force the transformation. A lens would be any method with the signature f : Collection <A>, fn (A, int -> Maybe A) -> Collection <A>, that is, it takes a function that can map and/or filter individual elements, to return a new collection. The passed in function should take both an element and an index, to allow for methods like take and drop An evaluator would either be the special method `collect`, which just transforms a collection via its nested collection of lenses (e.g. b = a.map(f).filter(g).map(h).collect()), or a function of the form Collection <A> , B, fn (A, B, int -> B) -> B, which reduces the collection to a scalar (e.g. fold or count). That should get around the problems associated with giving the user the intermediate iterators, while not unnecessarily allocating. Also, now that vala has support for generic delegates, we can try playing with a very simple Collection -> Collection set of methods, just to get a feel for the api. martin _______________________________________________ libgee-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/libgee-list
