On 23/07/10 11:44, Martin DeMello wrote: > On Wed, Jul 14, 2010 at 9:01 AM, Maciej Piechotka <uzytkownik2 gmail com> 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 I'm sorry but I fail to see how does it work. Could you show what exactly map or other transformation would look like (even in terms of interface?). Regards
Attachment:
signature.asc
Description: OpenPGP digital signature