Collectors update, bikeshed edition

[Joe Bowbeer]

David, I doubt there is a clear answer to your question, though I would
point to Ruby, Python and Groovy, in some order, for guidance as to what
Java programming students may have been exposed to.

This is an interesting take on the "inject" name in Ruby:

http://railspikes.com/2008/8/11/understanding-map-and-reduce

inject, reduce, and fold have all been used for "reduce" in Ruby.  inject
is apparently from Smalltalk?  I like the section "Why 3+ names".

My preferences are guided by how the simple examples "read", and I like the
way "collect" reads in the Anagrams example:

  public static Stream<Collection<String>> anagrams(Stream<String> words) {
    return words.parallel().collectUnordered(groupingBy(Anagrams::key))
          .values().parallelStream().filter(v -> v.size() > 1);
  }

Based on my own experience learning this complicated API, I think the best
approach for teaching these methods will be heavily reliant on a cookbook
of simple examples.

--Joe


On Thu, Feb 7, 2013 at 6:03 PM, David Holmes <david.holmes at oracle.com>wrote:

> I'm coming at this from a position of complete ignorance. I've never
> learnt functional programming though I had been exposed to some functional
> style of operations. The names collect/inject/fold are all equally
> meaningless to me. While I think I know what groupBy does I don't recognize
> it as a concrete instance of some abstract concept (folding, injection,
> aggregating etc).
>
> So my question is, for people who will learn Java through the
> primary/traditional channels (is schools, college, university etc), where
> would they learn the underlying concepts that these API's pertain to? And
> what terminology are they most likely to encounter there?
>
> FWIW I would much rather have a name with no obvious meaning than a name
> that I'm likely to think means something quite different to what it is.
> (unfortunately that is likely to apply to any verb we might use here.)
>
> David
>
>
> On 8/02/2013 11:38 AM, Brian Goetz wrote:
>
>> Don has been filling my mailbox daily brainstorming alternate names for
>> "collect".  If we were to rename collect, the ones that seems most
>> tolerable (largely on the basis of prior art) are "inject" and "fold".
>> Inject is the name used by Smalltalk, Ruby, and Groovy for this.  Again,
>> not that I'm claiming that this is any sort of proof of superiority, but
>> some people will be familiar with the name, and that's worth something.
>>
>> When I first came across "inject" I didn't like it.  Its primary value
>> seemed to that it rhymed with {sel,rej,det,inf,negl}ect.  But, like
>> "fold" (in the baking sense), there's a physical analogy of injecting
>> ingredients one at a time into a larger entity or aggregation that
>> absorbs them.  It rubs most people the wrong way at first, but you do
>> get used to it, and eventually it makes sense.
>>
>> Anyway, not to get Don's hopes up, but inject does have one big benefit
>> over collect, and that is the challenges faced by Collector.  One of the
>> bad things about the name Collector is that it *doesn't* actually
>> collect things!  Instead, it is a template/recipe/scheme for *how* to
>> collect things.  But we can't use the word Collection because that
>> clearly means something else, and
>> CollectorTemplate/**CollectorStrategy/**CollectorScheme all seem too
>> roundabout.
>>
>> But Injector works better as a name for what we now call Collector; you
>> can convince yourself that a groupBy() injects data into a Map.  Or, if
>> you don't like that, the space of InjectionXxx is open (unlike with
>> collect), such as InjectionScheme.
>>
>> I could tolerate switching to inject and some flavor of
>> Injector/InjectionScheme.  I could also tolerate fold(), but that is
>> more likely to engender "that's not a fold", and Folder has the same
>> problem as Collection.
>>
>> .NET calls this Aggregate, by the way.  And Aggregator is clear too.
>> Though Doug wants us to keep Aggregate free for some future Collection
>> type, and given how rabid I've been about things like syntactic
>> real-estate management, I think I must reluctantly agree.
>>
>>
>> On 1/30/2013 3:42 PM, Raab, Donald wrote:
>>
>>> In my opinion, collect should return a collection.  It should not
>>> reduce to any result.  In the interest of time, here's a stab at an
>>> alternative list I came up with using the powers of thesaurus yesterday:
>>>
>>> into
>>> gather
>>> assemble
>>> summarize
>>>
>>> The functionality currently called collect feels more like
>>> injectInto/inject in Smalltalk/Ruby/Groovy, but nothing is being
>>> injected into the method collect directly, but by the Collector (the R
>>> in makeResult()).  InjectInto/inject is the equivalent of foldLeft.  I
>>> would be less concerned over using injectInto or inject than collect,
>>> as at least it seems similar enough in that it can return any value,
>>> determined by the injector (currently called Collector).  But folks
>>> here might consider injectInto and foldLeft too cryptic, so I decided
>>> to just shorten to into in the above list.
>>>
>>> http://groovy.codehaus.org/**groovy-jdk/java/util/**
>>> Collection.html#inject(groovy.**lang.Closure)<http://groovy.codehaus.org/groovy-jdk/java/util/Collection.html#inject(groovy.lang.Closure)>
>>>
>>>
>>> In the binary release I have (not sure if this is different in current
>>> source), two of the overloaded versions of the method collect create a
>>> FoldOp today (a hint), and the Collector interface has a method called
>>> accumulate and combine and is called MutableReducer in the javadoc.
>>> The methods named reduce also create FoldOp instances.  This makes
>>> reduce and collect seem eerily similar.
>>>
>>> I find this a little confusing, but I have tried my best anyway to
>>> name that which by any other name seems to be more like
>>> injectInto/mapReduce/foldL/**aggregate/etc. to me.
>>>
>>> Thoughts?
>>>
>>>     I will do
>>>>> my best and find an alternative that everyone else here likes.
>>>>>
>>>>
>>>> Thanks.
>>>>
>>>> -Doug
>>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130207/48d58f1e/attachment.html