enh req: more granular SortedSetMultimap interface

[GoogleCodeExporter]

The SortedSetMultimap interface guarantees ordering of values, but not of
keys.  The concrete TreeMultimap guarantees ordering of both. 
Unfortunately, I need a SetMultimap with guaranteed ordering of keys but
not of values.

Looking at the approach taken in ReferenceMap, where you can express
policies/traits for keys and values independently (thereby allowing all
permutations), would it be possible to take the same approach with multimaps?

Original issue reported on code.google.com by dan.ro...@gmail.com on 27 Nov 2008 at 12:57

[GoogleCodeExporter]

You can create such a multimap with the Multimaps.newMultimap method:

public static <K,V> SetMultimap<K,V> newSetMultimap(Map<K,Collection<V>> map,
                                                    Supplier<? extends Set<V>> factory)

http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/col
lect/Multimaps.html#newSetMultimap(java.util.Map,%20com.google.common.base.Suppl
ier)

Provide a TreeMap as the map parameter, along with a factory that creates 
HashSets.

The Multimaps class also has similar newMultimap, newListMultimap, and
newSortedSetMultimap methods, all of which provide a lot of flexibility 
regarding the
behavior of the generated multimap.

Original comment by jared.l....@gmail.com on 27 Nov 2008 at 1:40

• Changed state: Fixed

[GoogleCodeExporter]

Interesting, I didn't know about this method.  Or I knew about it but I was too 
lazy
to wrap my head around what it might be good for.

My lazy head notwithstanding, I think there's still a problem with this 
approach... 
Although we can instantiate a multimap with the desired behavior, I think 
there's
still a typesafety issue when working with the interface.  For example, I'd want
keySet() to return a SortedSet<K>, similar to what SortedSetMultimap.get() does.

I guess what I'm trying to say is: I can has covariant returns plz?  Actually, I
noticed a related issue #81 logged here ... maybe that addresses my concerns?

Original comment by dan.ro...@gmail.com on 27 Nov 2008 at 3:04

[GoogleCodeExporter]

Your request leads to some complications.

As you know, a multimap definition has two orderings: the key ordering and the 
value 
ordering. The ListMultimap / SetMultimap / SortedSetMultimap interfaces 
characterize 
the behavior of the value collection for a given key. The key ordering is an 
orthogonal dimension, which could be represented by a SortedKeyMultimap 
interface.

The SortedKeyMultimap interface would ideally include some methods that 
TreeMultimap 
does not currently possess. SortedKeyMultimap.asMap() should return a 
SortedMap. In 
addition, SortedKeyMultimap could have headMultimap, tailMultimap, and 
subMultimap 
methods, which return multimaps containing a subset of the keys. Those methods 
would 
require a lot of effort, and nobody has asked for them.

In addition, having two dimensions of multimap sub-interface would lead to a 
scary 
assortment of APIs, and I don't think the resulting confusion would justify the 
added 
functionality.

FYI, the newMultimap, newSetMultimap, newSortedMultimap, and newListMultimap 
methods 
all generate multimaps whose keySet() method returns a SortedSet, as long as 
the 
backing map passed has a keySet() method returning a SortedSet. However, that 
behavior is, deliberately, not documented.

Original comment by jared.l....@gmail.com on 27 Nov 2008 at 3:43