Thanks for pointing this out. However, implementing Get & Put directly would pose the following problems.
If interface MultiValuedMap<K,V> extends Get<K,Collection<V>> the method "values" would be forced to have a signature of Collection<Collection<V>> values() whereas we would want Collection<V> values(). This wont be possible as we would extend Get with the generics <K,Collection<V>> as we want the method "get" to have a signature like Collection<V> get(Object key) Now, extending the Put interface with generics <K,V> does not pose that much of an issue except that the Map interface in Java 7 has a put signature as V put(K key, V value) whereas the Collections 4 Put still has Object put(Key k, V value), but we can ignore this if we want. For the problem with Get, we can have a parallel MultiValuedGet and MultiValuedPut interfaces to honor the Get/Put split concepts. Although we don't really need the MultiValuedPut, we can have that for consistency. Let me know your thoughts on this. Regards Dipanjan On Wed, Feb 26, 2014 at 7:12 PM, Matt Benson <gudnabr...@gmail.com> wrote: > Don't forget about the Get/Put/split map concepts from Collections 4. It > would seem you could implement those interfaces and provide that amount of > abstraction anyway. > > Matt > On Feb 26, 2014 3:26 AM, "Dipanjan Laha" <dipanja...@gmail.com> wrote: > > > Hi Thomas, > > > > This sounds great. Moving MultiKeyMap to the new package does sound like > > the way to go ahead. I will start with the implementation of the > interface > > and the MultiValuedHashMap. I should be able to submit a patch with a > basic > > implementation and some test cases by the end of this week. I can then > > modify and incorporate changes as per your review and suggestions. > > > > Regards > > Dipanjan > > > > > > On Wed, Feb 26, 2014 at 2:32 PM, Thomas Neidhart > > <thomas.neidh...@gmail.com>wrote: > > > > > Hi Dipanjan, > > > > > > I was thinking about a name for the new interface, but I actually like > > your > > > proposal of MultiValuedMap. > > > > > > For the package, I think we can stick with multimap, and at some point > we > > > could also move the MultiKeyMap there, which would be logical imho. > > > > > > The implementation names are also sound. > > > > > > Thomas > > > > > > > > > > > > > > > On Wed, Feb 26, 2014 at 9:28 AM, Dipanjan Laha <dipanja...@gmail.com> > > > wrote: > > > > > > > Hi Thomas, > > > > > > > > It would be great if we can start the discussion on the new interface > > for > > > > MultiMap and a new package for the implementations as suggested by > you. > > > > Then I'll be able to put some code together for the same. > > > > > > > > IMO we can have > > > > > > > > 1. New Interface for MultiMap with the name MultiValuedMap or > > MultiValMap > > > > (as MultiValueMap is already the existing implementing class). > > > > 2. New package for the implementations: > > > > org.apache.commons.collections.multimap or > > > > org.apache.commons.collections.multivaluedmap > > > > 3. Implementation names like : MultiValuedHashMap, MultiValuedTreeMap > > etc > > > > > > > > Please let me know of your thoughts on these. > > > > > > > > Regards > > > > Dipanjan > > > > > > > > On Sun, Feb 23, 2014 at 8:36 PM, Dipanjan Laha <dipanja...@gmail.com > > > > > > wrote: > > > > > > > > > Hi Thomas, > > > > > > > > > > Thanks for your feedback. I created an improvement request in Jira > > for > > > > the > > > > > same (https://issues.apache.org/jira/browse/COLLECTIONS-508 ) as I > > > > > thought it could be better tracked there. Sorry for the duplication > > in > > > > the > > > > > mail list and Jira. I have also attached a patch in Jira where I > have > > > > > modified the existing MultiMap interface and the MultiValueMap > > > > > implementation and their test cases. I agree that it would break > > > backward > > > > > compatibility and we should go with your suggestion of deprecating > > the > > > > > existing ones and design fresh interfaces for the same. The patch > is > > > > just a > > > > > sample implementation to demonstrate the issue and is far from > being > > > > > complete in terms of documentation and test cases. I am also > > attaching > > > > the > > > > > patch here for your reference. > > > > > > > > > > Please go through the patch and also let me know of your thoughts > on > > > how > > > > > we should proceed with the new interface and package structure. > I'll > > be > > > > > happy to change and redirect the implementation as per your > > > suggestion. I > > > > > am new to Apache Commons, but with some guidance I should not have > > > issues > > > > > implementing them to start with. > > > > > > > > > > As for MultiTrie, as you mentioned, we can start with it once the > new > > > > > MultiMap has been finalized. > > > > > > > > > > Regards > > > > > Dipanjan > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Feb 23, 2014 at 6:09 PM, Thomas Neidhart < > > > > > thomas.neidh...@gmail.com> wrote: > > > > > > > > > >> On 02/22/2014 02:00 PM, Dipanjan Laha wrote: > > > > >> > Hello, > > > > >> > > > > >> Hi Dipanjan, > > > > >> > > > > >> > Recently I had the need of using a MultiMap in one of my > > projects. I > > > > >> found > > > > >> > that commons collection already has a MultiMap interface and an > > > > >> > implementation. > > > > >> > > > > > >> > While using the same, I found that the MultiMap interface has > > > methods > > > > >> that > > > > >> > are not strongly typed even though the interface supports > > generics. > > > > For > > > > >> > example if I have a MultiMap like so > > > > >> > > > > > >> > MultiMap<String, User> multiMap = new MultiValueMap<String, > > User>(); > > > > >> > > > > > >> > where User is a custom Class, then the get(key) method would > > return > > > > me > > > > >> an > > > > >> > Object which I would need to cast to a Collection like so > > > > >> > > > > > >> > Collection<User> userCol = (Collection<User>) multiMap.get(key); > > > > >> > > > > > >> > I understand that this limitation comes from that fact that the > > > > MultiMap > > > > >> > extends IterableMap which in turn extends Map and other > > interfaces. > > > > >> Hence > > > > >> > the MultiMap cannot have a get method which returns a Collection > > > > >> instead of > > > > >> > Object as that would mean extending IterableMap with the > Generics > > > set > > > > >> to be > > > > >> > <K,Collection<V>>. In that case the put method's signature would > > > > become > > > > >> > > > > > >> > public Collection<V> put(K key, Collection<V> value); > > > > >> > > > > > >> > which we do not want.The same problem would arise with other > > methods > > > > as > > > > >> > well, ex: containsValue method. > > > > >> > > > > > >> > My proposal is why carry on the signatures of a Map and put it > on > > > > >> MultiMap. > > > > >> > Where as I do agree that it is a Map after all and has very > > similar > > > > >> > implementation and functionality, it is very different at other > > > > levels. > > > > >> And > > > > >> > even though the MultiMap interface supports generics, the > methods > > > are > > > > >> not > > > > >> > strongly typed, which defeats the purpose of having generics. So > > why > > > > >> can't > > > > >> > we have a separate set of interfaces for MultiMap which do not > > > extend > > > > >> Map. > > > > >> > That way we can have strongly typed methods on the MultiMap. > > > > >> > > > > >> The MultiMap interface as it is right now is flawed, and should > have > > > > >> been cleaned up prior to the 4.0 release imho (and I regretted it > > > > >> already before your post). > > > > >> > > > > >> As you correctly pointed out, the problem comes from the fact that > > it > > > > >> extends Map<K, Object> which leads to problems once generics have > > been > > > > >> introduced (before it did not matter that much as you had to cast > > > > >> anyway, as it is also documented in the javadoc). > > > > >> > > > > >> One mitigation for this was the introduction of this method to > > > > >> MultiValueMap, but it is clearly not enough: > > > > >> > > > > >> public Collection<V> getCollection(Object key) > > > > >> > > > > >> > > > > >> Unfortunately, it is not easy to fix this now after collections > 4.0 > > > has > > > > >> been released. We need to keep backwards compatibility, but we > could > > > do > > > > >> the following: > > > > >> > > > > >> * deprecate the existing interfaces/classes: > > > > >> - MultiMap > > > > >> - MultiValueMap > > > > >> > > > > >> * design a new, clean interface (by not extending Map) > > > > >> * add new package multimap with concrete implementations for > > > different > > > > >> types of maps (right now only hashmaps are supported) > > > > >> > > > > >> > Please let me know your thoughts on this. I can submit a patch > for > > > > these > > > > >> > changes based on your feedback. One more thing, I also am in > need > > > of a > > > > >> > MultiTrie which is currently not there. I am implementing the > same > > > by > > > > >> > wrapping PatriciaTrie. Now I am a bit confused here as, if I > make > > > the > > > > >> > MultiTrie interface on the lines of MultiMap, it would have the > > same > > > > >> > limitations. In that case I was planning to have a separate set > of > > > > >> > interfaces for MultiTrie which does not extend any other > > interface. > > > > And > > > > >> in > > > > >> > case, we do change the MultiMap interface to be independent of > > Map, > > > > then > > > > >> > MultiTrie can extend MultiMap. Please let me know your thoughts > on > > > > this > > > > >> as > > > > >> > well as I am implementing the same for my project right now and > > > would > > > > >> like > > > > >> > to contribute it back to the commons collection. > > > > >> > > > > >> Patches are always welcome, but we first need a decision in which > > > > >> direction to go, see above. > > > > >> > > > > >> Regarding the MultiTrie: > > > > >> > > > > >> Indeed, it is the same problem, so it should go hand in hand with > > the > > > > >> revamp of the MultiMap interface. > > > > >> > > > > >> Thomas > > > > >> > > > > >> > > --------------------------------------------------------------------- > > > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > >> > > > > >> > > > > > > > > > > > > > > >
