[
https://issues.apache.org/jira/browse/COLLECTIONS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922256#comment-13922256
]
Thomas Neidhart commented on COLLECTIONS-508:
---------------------------------------------
{quote}
IMHO I think containsMapping goes well with removeMapping. What do you think?
{quote}
thats fine for me.
Regarding the List & Set MultiValuedMap, what we could do there is to hide this
detail completely in the implementation and just provide static factory methods
that return a generic MultiValuedMap with either a List or Set as backing
collection class. The interfaces ListMultiValuedMap and SetMultiValuedMap would
just act as marker interfaces to make the intent clear. I will give it a try
with your current patch and see if this can work.
Regarding MultiValuedSet vs Bag:
The MultiValuedSet I had in mind (probably a bad name) is the same as the
CollectionBag is now, it counts the number of times an object is in this Set
the same as the Bag does, but follows the Collection contract. I would see it
as a design goal to make all collection classes compliant with the Collection
contract. This would make the use of collections less error-prone, but I
understand that there are people who value the Bag interface as it is now.
> MultiMap's methods are not strongly typed even though the interface supports
> generics
> -------------------------------------------------------------------------------------
>
> Key: COLLECTIONS-508
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-508
> Project: Commons Collections
> Issue Type: Improvement
> Components: Map
> Affects Versions: 4.0
> Reporter: Dipanjan Laha
> Attachments: MultiValuedMap.patch
>
>
> Recently I had the need of using a MultiMap in one of my projects. 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 implementing 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.
> I have included a a patch for these changes. It is not fully complete and has
> some gaps in some TestCases and the documentation but gives a fairly good
> idea of what I am talking about. Please let me know your thoughts on taking
> this approach. Then i will improve the implementation and submit another
> patch.
> The other way could be that we let MultiMap extend the interfaces it does
> today, but with proper types rather than Object. I mean something like this
> public interface MultiMap<K,V> extends IterableMap<K,Collection<V>> instead
> of
> public interface MultiMap<K,V> extends IterableMap<K,Object>
> And then have a separate set of methods on the MultiMap interface which
> supports the specific MultiMap functionality. For example, the put method
> with the above implementation would become
> Collection<V> put(K key, Collection<V> value)
> and we can have another method as
> V putValue(K key, V value)
> This way the functionality of Map is preserved along with strongly typed
> MultiMap methods. If you feel that this approach is better than the earlier
> one, i will implement the same and submit a patch
--
This message was sent by Atlassian JIRA
(v6.2#6252)
