Collectors update, bikeshed edition

[Kevin Bourrillion]

I come from an environment where usage of @javax.inject.Inject is just
utterly ubiquitous, so I really *can't* like inject() for this.


On Thu, Feb 7, 2013 at 5:38 PM, Brian Goetz <brian.goetz at oracle.com> 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
>>>
>>
>>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130207/09d617d0/attachment-0001.html