fluent multimap utilities

[GoogleCodeExporter]

Utility methods for Iterables, Lists, Maps and Collections are created as 
static methods in utility classes. Using these static methods can be annoying, 
so we have FluentIterable.

Utility classes also exist for Multimaps in a similar form, and can be 
similarly annoying to use. I would therefore like a similar fluent interface to 
Multimap operations. However, since the guava team controls the Multimap 
interface, I see no reason for a wrapper class and suggest the methods simply 
be added to Multimap.

Compare:

Multimap<Integer,Double> iToDs;
Multimap<Integer,String> someIsToSs = 
Multimaps.transformValues(Multimaps.filterKeys(iToSs, Predicates.in(someSet), 
Functions.toStringFunction())

vs.

Multimap<Integer,String> someIsToSs = iToDs
    .filterKeys(Predicates.in(someSet))
    .transformValues(Functions.toStringFunction())

One issue I see with this is the one that already exists with asMap and was 
addressed with the addition of static asMap methods; if you have a 
(Set|List|X)Multimap and do these transformations, the type system loses the 
knowledge of (Set|List|X)ness.

Original issue reported on code.google.com by br...@iheardata.com on 13 Sep 2013 at 4:24

[GoogleCodeExporter]

Original comment by lowas...@google.com on 13 Sep 2013 at 5:00

• Added labels: Package-Collect, Type-Addition

[GoogleCodeExporter]

Off the top of my head, I have a few concerns --

1) Will this increase the complexity of a future Java 8 migration to do this 
now?
2) Is it a good idea to create asymmetries with the JDK collection types?  All 
the Guava collections' APIs are designed to be pretty similar to the JDK 
collections'.
3) Are there users out there implementing the Multimap interface who would be 
broken by this change?

Original comment by lowas...@google.com on 13 Sep 2013 at 5:04

[GoogleCodeExporter]

Please note that FluentIterables don't modify the underlying/original Iterable: 
their methods produce lazily-computed views (represented as _new_ 
FluentIterable objects) or new (immutable) objects that are merely derived from 
the original.

Contrast that with the existing methods on Multimap (and other data structure 
classes): those are either destructive (in the sense that they immediately 
modify the state of the object on which they're invoked) or produce a view that 
is updated whenever the underlying object is.

I worry that mixing these fundamentally different patterns will yield quite a 
bit of confusion, forcing users to refer to the JavaDoc more than should be 
necessary. In that light having a separate "FluentMultimap" class might not be 
such a bad idea.

Original comment by stephan...@gmail.com on 13 Sep 2013 at 7:40

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<issue id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:12

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:17

• Changed state: Migrated

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:08

• Added labels: Restrict-AddIssueComment-Commit