Yet another run at reduce (collect) (original) (raw)
Tim Peierls tim at peierls.net
Wed Jan 9 05:53:10 PST 2013
- Previous message: Yet another run at reduce (collect)
- Next message: Yet another run at reduce (collect)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Yes! "collect" is good. I had been translating "reduce" into "collect" already in my head.
Of course then I'd want Reducers (Collectors?) like "toMap" and "toList" to be "intoMap" and "intoList".
--tim
On Wed, Jan 9, 2013 at 6:12 AM, Doug Lea <dl at cs.oswego.edu> wrote:
While scoping out this form of solution, Brian noticed that the new collecting form of reduce is overload-hostile to one of the existing reduce methods. (that is, has the same arity and has mutually-confusable lambda args.) Having been traumatized by this problem last week, I think we need to do something about this. He is not yet convinced that we will need to change this. I am. I propose renaming this form "collect", and the corresponding interface to Collector. The underlying concept here is, in Fortress-ese, catamorphic reduction, but the closest non-weird term is "collect". Much closer than "accumulate". And further, I think this is a net positive win in terms of understandability. For example: reduce(intoList()) => collect(intoList()) The name provides a pleasant and appropriate clue that it is something often applicable to Collections. Try it out on other examples. I think you will like it better unless you are Brian :-) And if we don't do this, people will be getting mile-long overload ambiguity messages from Javac in surprising contexts. -Doug
- Previous message: Yet another run at reduce (collect)
- Next message: Yet another run at reduce (collect)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-observers mailing list