Yes! "collect" is good. I had been translating "reduce" into "collect" already in my head.<div><br></div><div>Of course then I'd want Reducers (Collectors?) like "toMap" and "toList" to be "intoMap" and "intoList".</div>
<div><br></div><div>--tim<br><br><div class="gmail_quote">On Wed, Jan 9, 2013 at 6:12 AM, Doug Lea <span dir="ltr"><<a href="mailto:dl@cs.oswego.edu" target="_blank">dl@cs.oswego.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
While scoping out this form of solution, Brian noticed that the<br>
new collecting form of reduce is overload-hostile to<br>
one of the existing reduce methods. (that is, has the same arity<br>
and has mutually-confusable lambda args.) Having been traumatized<br>
by this problem last week, I think we need to do something about this.<br>
He is not yet convinced that we will need to change this. I am.<br>
<br>
I propose renaming this form "collect", and the corresponding<br>
interface to Collector. The underlying concept here is,<br>
in Fortress-ese, catamorphic reduction, but the closest<br>
non-weird term is "collect". Much closer than "accumulate".<br>
<br>
And further, I think this is a net positive win in terms of<br>
understandability. For example:<br>
<br>
reduce(intoList()) => collect(intoList())<br>
<br>
The name provides a pleasant and appropriate clue that it is<br>
something often applicable to Collections.<br>
<br>
Try it out on other examples.<br>
I think you will like it better unless you are Brian :-)<br>
<br>
And if we don't do this, people will be getting mile-long<br>
overload ambiguity messages from Javac in surprising<br>
contexts.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Doug<br>
<br>
<br>
</font></span></blockquote></div><br></div>