Iterables.toMap

[GoogleCodeExporter]

I've implemented a Method, to create a Map from an Iterable that might be 
useful:

public static <E,F> Map<F,E> toMap(Iterable<E> iterable, final Function<? super 
E, ? extends F> keySelector)
public static <E,F,G> Map<F,G> toMap(Iterable<E> iterable,final Function<? 
super E, ? extends F> keySelector,final Function<? super E,? extends G> 
valueSelector)

The Implementation and Test ist appended.

Original issue reported on code.google.com by nvoll...@gmail.com on 12 Jan 2011 at 4:24

Attachments:

• ToMap.patch

[GoogleCodeExporter]

Your first method there is equivalent to Maps.uniqueIndex... the second method 
is more or less equivalent to using Maps.transformValues on the result of 
Maps.uniqueIndex and then copying that as a non-view Map.

As a side note, Guava has a built in Function called Functions.identity() that 
does what your "defaultSelector" Function in the implementation of the first 
method does.

Original comment by cgdec...@gmail.com on 12 Jan 2011 at 7:18

[GoogleCodeExporter]

Original comment by kevinb@google.com on 12 Jan 2011 at 8:33

• Changed state: WontFix

[GoogleCodeExporter]

Hey nvollmar,

Thanks for sharing this! I might re-use the toMap(iterable, keySelector, 
valueSelector) idea in some of my own projects. I won't need the other one, 
because I already use Maps.uniqueIndex() for this use case.

I think it would be great if your methods handled duplicate keys. Currently, if 
there are duplicate keys, the previous one is silently overridden. It might be 
dangerous.
Maps.uniqueIndex() does this, because it uses an ImmutableMap.Builder 
internally, which throws an IllegalArgumentException when it encounters 
duplicate keys. You might want to base your method on ImmutableMap.Builder too, 
if mutability is not mandatory.

Another small nitpick: I think I would remove the "final" modifier from your 
method parameters. They add unnecessary clutter to the code. I only use final 
parameters when I must access them from an anonymous class. I guess it's a 
style choice, though :)

All that being said, while these are interesting methods, I think the Guava 
developers won't include them, because they try to keep a high "power to 
weight" ratio for their API. I talked a little bit about this idea in this 
StackOverflow question: 
http://stackoverflow.com/questions/4542550/what-are-the-big-improvements-between
-guava-and-apache-equivalent-libraries
I think they won't want to include a method that, while useful, would not be 
used *that* often, and whose behavior is relatively easily obtained by 
combining various other Guava components (in this case, as Colin said, 
Maps.transformValues() and Maps.uniqueIndex()).

Original comment by nev...@gmail.com on 12 Jan 2011 at 10:10

[GoogleCodeExporter]

Thanks for your input, didn't think of that.

I guess I've should have picked another place to share it.

Original comment by nvoll...@gmail.com on 13 Jan 2011 at 7:53

[GoogleCodeExporter]

Well, it's still a good idea to share. You never know how many people might 
want to do the same thing!

It would be great if we had some kind of "guava-extensions" project, that would 
contain all the nice extensions / utility methods that build upon Guava, but 
weren't included in Guava proper (because the library would be to big).

Original comment by nev...@gmail.com on 13 Jan 2011 at 9:32

[GoogleCodeExporter]

This issue has been migrated to GitHub.

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

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

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

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

• Added labels: Restrict-AddIssueComment-Commit