ImmutableMap.copyOf(Iterable<Map.Entry<K, V>>) #320
Comments
|
Original comment posted by finnw1 on 2010-12-08 at 12:07 PM The interface proposed in Issue #330 would also solve this. |
|
Original comment posted by fry@google.com on 2011-01-28 at 03:58 PM Why not simply use ImmutableMap.copyOf(Map)? |
|
Original comment posted by fry@google.com on 2011-01-28 at 04:02 PM (No comment entered for this change.) Labels: |
|
Original comment posted by kevinb9n on 2011-01-28 at 09:00 PM I think the answer to that question is "because what have is a Set<Entry>, not a Map." I am not clear on why exactly users find themselves in this situation, but plan to look deeper into it. Status: |
|
Original comment posted by daniel.yokomizo on 2011-01-28 at 10:55 PM I regularly start with Iterable<E> and end up with Iterable<Map.Entry<K,V>> where sometimes E=K or E=V, it's much simpler to keep working with Iterable<Map.Entry<K,V>> and only in the end instantiate a Map<K,V>. |
|
Original comment posted by wasserman.louis on 2011-03-08 at 08:26 PM It strikes me that while an Iterable<Map.Entry<K,V>> does not always represent the entrySet() of a Map, it could be the entrySet() of a Multimap. Perhaps we should look at it in that way instead? |
|
Original comment posted by kevinb@google.com on 2011-03-09 at 03:07 PM That is probably the best case anyone's made yet for the value of methods accepting Iterable<Map.Entry>! I am smacking myself for never thinking of it this way -- how many times I've lamented that Map and Multimap implement no common interface! If someone would look through the whole API for any examples of methods that would really want to accept either Map or Multimap (meaning that they can plausibly deal with duplicate keys), then we can look at the feasibility of It<Entry>-accepting versions of those methods. |
|
Original comment posted by wasserman.louis on 2011-03-09 at 05:53 PM I'm not sure I follow. I haven't yet found any methods that "would really want to accept either Map or Multimap," but here's the point I was initially trying to make: If we're presented with an Iterable<Map.Entry<K,V>>, we don't have any guarantee that the keys are distinct. (Map.entrySet() returns a Set<Entry<K,V>> for precisely the reason that we're certainly guaranteed that there are no duplicate entries.) However, any Iterable<Map.Entry<K,V>> could be the entries() of a Multimap, regardless of duplication. In particular, I'd certainly support a LinkedListMultimap.create(Iterable<Entry<K,V>>), with the result that the entries() of the resulting multimap would be the same entries in the same order. Another, related, possibility would be Multimap.putAll(Iterable<Entry<K,V>>), since there is currently no putAll(Map<K,V>). |
|
Original comment posted by j...@nwsnet.de on 2011-03-31 at 12:03 PM I'd like to see the addition of methods to create a map from I'm not sure about the MultiMap-related discussion here; currently I'm just concerned about basic maps. |
|
Original comment posted by cgdecker on 2011-04-14 at 03:54 AM MapJoiner is an example of something I'd like to see support Multimap as well as Map... I wanted to be able to do this for some code I was playing with recently. I wrote up the code for that and was going to submit a separate issue, but was reminded of this. |
|
Original comment posted by cgdecker on 2011-04-14 at 04:01 AM Just realized that supporting Multimap directly in MapJoiner would break the package-dependency rule I seem to recall seeing mentioned at some point, but Iterable<Map.Entry> wouldn't. |
|
Original comment posted by kevinb@google.com on 2011-07-13 at 06:18 PM (No comment entered for this change.) Status: |
|
Original comment posted by fry@google.com on 2011-12-10 at 03:43 PM (No comment entered for this change.) Labels: |
|
Original comment posted by wasserman.louis on 2012-01-11 at 05:13 PM Issue #861 has been merged into this issue. |
|
Original comment posted by fry@google.com on 2012-02-16 at 07:17 PM (No comment entered for this change.) Status: |
|
Original comment posted by wasserman.louis on 2012-02-17 at 07:08 PM ...I observe that creating maps from iterables of entries is listed in the Idea Graveyard. (I'm working on justifying it, though...?) |
|
Original comment posted by finnw1 on 2012-02-17 at 07:13 PM @wasserman.louis, see also kevinb's comment on Issue 385 |
|
Original comment posted by wasserman.louis on 2012-02-17 at 07:17 PM Ah. I did not see that. |
|
Original comment posted by kevinb@google.com on 2012-05-30 at 07:43 PM (No comment entered for this change.) Labels: - |
|
Original comment posted by kevinb@google.com on 2012-06-22 at 06:16 PM (No comment entered for this change.) Status: |
|
Original comment posted by wasserman.louis on 2012-08-14 at 07:18 PM Issue #1107 has been merged into this issue. |
|
Original comment posted by wasserman.louis on 2012-08-14 at 07:19 PM Issue #1107 has been merged into this issue. |
|
Original comment posted by lukes@google.com on 2012-08-14 at 07:23 PM Issue #1107 has been merged into this issue. |
|
Original comment posted by jaredjacobs on 2012-10-05 at 11:39 PM Kevin, to contribute to your research effort, here's the reason I currently need this: Someone implemented something as a List<Pair> that really should have been a Map. I'm writing some temporary translation code for backwards compatibility. (Yes, it's temporary, but I'd still like it to be concise and readable.) |
|
Original comment posted by kak@google.com on 2012-10-23 at 04:45 PM Issue #1116 has been merged into this issue. |
|
Original comment posted by kevinb@google.com on 2012-10-23 at 04:45 PM Also consider varargs Entries, consider Builder. |
|
Original comment posted by ceefour666 on 2012-11-03 at 03:45 PM I highly support this. Also for Multimaps please :
static Maps.putAll(Map<K, V>, Iterable<Map.Entry<K, V>>) I also request similar addition but for Multiset, please vote issue #1189 too :-) |
|
Original comment posted by lowasser@google.com on 2012-11-23 at 04:05 PM http://stackoverflow.com/questions/13527055/how-to-create-a-treemultimap-from-an-iterable-collection/13532402#13532402 seems like a genuinely valid use case for the Multimap variant. Tldr: Iterables.limit on an Iterable of entries is a reasonable need, though I'd imagine that applies only when the entries have some predictable order. The Map variant would usually be something like Ordering.least of for sorted maps? |
|
Original comment posted by adomma...@axian.com on 2014-06-26 at 12:07 AM Also, in gson, the JsonObject has an entrySet() method - but it would be nice to directly convert that into a Map (instead of littering iteration code everywhere). |
|
Original comment posted by lowasser@google.com on 2014-09-26 at 09:43 PM We were convinced internally that there was a need for this; it's been added, and the change will be mirrored out soon. Status: |
gissuebot
added
status=fixed
migrated
type=addition
|
Looks like this should be removed from the idea graveyard, now that it's been implemented:
|
|
Updated, thanks. |
Original issue created by finnw1 on 2010-01-30 at 09:49 AM
I often want to create a Map from its entrySet. I've rolled my own version
of this in a few of my projects. It would be nice to have a standard API
for it.
The text was updated successfully, but these errors were encountered: