More convenience methods for Maps, SortedMap please!

[GoogleCodeExporter]

Would it make sense to have static convenience methods such as:

public static <K,V> ImmutableMap<K,V> sum(Map<K,V> x, Map<K,V> y){ ... }

public static <K,V> ImmutableSortedMap<K,V> sum(SortedMap<K,V> x, 
SortedMap<K,V> y){ ... }
public static <K,V> ImmutableSortedMap<K,V> sum(Map<K,V> x, Map<K,V> y){ ... }

in ImmutableMap and ImmutableSortedMap?

Right now I have to do the following:

ImmutableMap.<K,V>builder().addAll(x).addAll(y).build();
ImmutableSortedMap.<K,V>naturalOrder().addAll(x).addAll(y).build();

which is not too bad actually but I assume having a static method might allow 
for some optimization (views, etc.).

Thoughts?

Original issue reported on code.google.com by amojo...@gmail.com on 28 Mar 2014 at 5:46

[GoogleCodeExporter]

We couldn't return an immutable map as a view, since that could be changed out 
from under you.  Is it critical to have the immutable return type?

Part of my concern is that if you are returning a view, you have to have some 
semantics for the case where the maps have overlapping keys, other than 
throwing whenever you encounter them; that just becomes a time bomb waiting to 
happen.

Original comment by lowas...@google.com on 28 Mar 2014 at 6:04

[GoogleCodeExporter]

I meant you can safely return a view if both maps are immutable.

The issue about key overlap is bigger. The behavior should probably be very 
conservative and throw when the keys overlap. That will cover at least some use 
cases. If I'm not wrong it's actually the behavior of the code I have that uses 
the builder. 

If more complicated logic is required to decide which (k,v) pair to choose 
among two, then users must implement the logic themselves. But that's ok since 
the requirements themselves are more complex. 

Original comment by amojo...@gmail.com on 28 Mar 2014 at 6:30

[GoogleCodeExporter]

The code that uses the builder throws eagerly if the keys overlap, but view 
methods should return in constant time: it could only throw lazily when it 
discovers, after the fact, that the keys overlap...or it could use some other 
kind of merging behavior.

Original comment by lowas...@google.com on 28 Mar 2014 at 8:45

[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:09

• 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:07

• Added labels: Restrict-AddIssueComment-Commit