Possible groupingBy simplification?

[Sam Pullara]

Don't know what it is, but I'd like it to throw an exception on clobber. My assumption is that in that case you know the keys are unique.

Sam

On Apr 10, 2013, at 1:00 PM, Tim Peierls <tim at peierls.net> wrote:

> Agreed. 
> 
> What mergeFn is used in two-arg toMap?
> 
> --tim
> 
> On Wed, Apr 10, 2013 at 3:45 PM, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> Looks good. I like the retention of the simple forms, and the telescopes.
> 
> On Apr 10, 2013 11:11 AM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
> After staring at groupingBy and toMap for a while, I think there's a nice middle ground which should address the key use cases while reducing a little bit of the "which one do I use":
> 
>   groupingBy(f)
>   groupingBy(f, downstreamCollector)
>   groupingBy(f, mapSupplier, downstreamCollector)
> 
>   toMap(keyFn, valFn)
>   toMap(keyFn, valFn, mergeFn)
>   toMap(keyFn, valFn, mergeFn, mapSupplier)
> 
> This cuts variants of each from 4 to 3, but more importantly, orders them into a nice telescoping set.
> 
> Those wanting the groupingBy(f, mapSUpplier) version should be able to figure out easily (with aid from doc) that they can use groupingBy(f, mapSUpplier, toList()).
> 
> On 4/10/2013 1:10 PM, Remi Forax wrote:
> Joe,
> collect(toList(), groupingBy(f));
>    => how do you express the fact that you may want to group in cascade ?
> 
> collect(groupingBy(f)).toList()
>    => what is the resulting type of collect(groupingBy(f)) ?
>          is it a super-type of Stream ?
> 
> Brian,
> I'm fine with the proposed changes.
> 
> Rémi
> 
> On 04/10/2013 06:42 PM, Joe Bowbeer wrote:
> 
> Correction: All the grouping(f) should be groupingBy(f)
> 
> On Apr 10, 2013 9:37 AM, "Joe Bowbeer" <joe.bowbeer at gmail.com
> <mailto:joe.bowbeer at gmail.com>> wrote:
> 
>     For consistency with minBy and friends, all the 'By' methods
>     should take a single argument: f. Hence grouping(f).
> 
>     No-arg and one-arg forms are the easiest to use and maintain. Just
>     the additional comma, and which pair of parens contains it, is a
>     significant burden.
> 
>     The most readable forms of collect that have an explicit toList()
>     would be of the form:
> 
>     collect(grouping(f)).toList();
> 
>     or maybe
> 
>     collect(toList(), groupingBy(f));
> 
>     Joe
> 
>     On Apr 10, 2013 2:35 AM, "Paul Sandoz" <paul.sandoz at oracle.com
>     <mailto:paul.sandoz at oracle.com>> wrote:
> 
> 
>         On Apr 9, 2013, at 11:56 PM, Joe Bowbeer
>         <joe.bowbeer at gmail.com <mailto:joe.bowbeer at gmail.com>> wrote:
> 
>         > I like the most popular form.  In fact, I think it's the
>         only one that I've
>         > used.
>         >
>         > The argument that users will gain by removing their most
>         common form seems
>         > kind of far-fetched.
>         >
> 
>         If each method in Collectors does just one conceptual thing we
>         can concisely express in documentation it is easier to
>         remember and therefore easier to read the code, easier to find
>         in documentation be it using the IDE or otherwise. Thus to me
>         that suggests removing conceptual variants or renaming them.
> 
>         If the list variants were called say groupingByToList that
>         would ensure the "one conceptual thing":  classifies elements
>         by key, and collects elements associated with that key to a
>         list. But i suspect we might not require those methods if the
>         leap of stream.collector(toList()) can be grasped.
> 
>         The same applies to toMap. I think it is easier to
>         understand/read if it does just one conceptual thing: elements
>         are keys, elements are mapped to values, conflicting keys
>         result in an exception. If that does not fit ones requirements
>         use groupingBy.
> 
>         Paul.
> 
>         > In my experience, I do a ctrl-space and look for my target
>         return type on
>         > the right-hand-side of the IDE popup, and then I try to fill
>         in the missing
>         > information, such as parameters.  In this case, having to
>         provide toList()
>         > would probably be a stumbling block for me, as the IDE is
>         not as good when
>         > it comes to suggesting expressions for parameters.
>         >
>         > I sort of like the symmetry with collect(toList()) but not
>         enough to make
>         > up for the loss.
>         >
>         >
>         >
>         > On Tue, Apr 9, 2013 at 2:16 PM, Brian Goetz
>         <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
>         >
>         >> Paul suggested the following possible simplification for
>         groupingBy.  It
>         >> is somewhat counterintuitive at first glance, in that it
>         removes the most
>         >> commonly used form (!), but might make things easier to
>         grasp in the long
>         >> run (aided by good docs.)
>         >>
>         >> Recall we currently have four forms of groupingBy:
>         >>
>         >>    // classifier only -- maps keys to list of matching
> elements
>         >>    Collector<T, Map<K, List<T>>>
>         >>    groupingBy(Function<? super T, ? extends K> classifier)
>         >>
>         >>    // Like above, but with explicit map ctor
>         >>    <T, K, M extends Map<K, List<T>>>
>         >>    Collector<T, M>
>         >>    groupingBy(Function<? super T, ? extends K> classifier,
>         >>               Supplier<M> mapFactory)
>         >>
>         >>    // basic cascaded form
>         >>    Collector<T, Map<K, D>>
>         >>    groupingBy(Function<? super T, ? extends K> classifier,
>         >>               Collector<T, D> downstream)
>         >>
>         >>    // cascaded form with explicit ctor
>         >>    <T, K, D, M extends Map<K, D>>
>         >>    Collector<T, M>
>         >>    groupingBy(Function<? super T, ? extends K> classifier,
>         >>               Supplier<M> mapFactory,
>         >>               Collector<T, D> downstream)
>         >>
>         >> Plus four corresponding forms for groupingByConcurrent.
>         >>
>         >> The first form is likely to be the most common, as it is
>         the traditional
>         >> "group by".  It is equivalent to:
>         >>
>         >>  groupingBy(classifier, toList());
>         >>
>         >> The proposal is: Drop the first two forms.  Just as users
>         can learn that
>         >> to collect elements into a list, you do:
>         >>
>         >>  collect(toList())
>         >>
>         >> people can learn that to do the simple form of groupBy, you
>         can do:
>         >>
>         >>  collect(groupingBy(f, toList());
>         >>
>         >> Which also reads perfectly well.
>         >>
>         >> By cutting the number of forms in half, it helps users to
>         realize that
>         >> groupingBy does just one thing -- classifies elements by
>         key, and collects
>         >> elements associated with that key.  Obviously the docs for
>         groupingBy can
>         >> show examples of the simple grouping as well as more
>         sophisticated
>         >> groupings.
>         >>
>         >>
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20130410/c45b48a7/attachment.html