[
https://issues.apache.org/jira/browse/COLLECTIONS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947266#comment-13947266
]
Thomas Neidhart commented on COLLECTIONS-508:
---------------------------------------------
In r1581553, I have committed the a cleaned up version of the patches.
Some things that I changes:
* removed size(Object) and iterator(Object), see rationale below
* added a ListValuedMap interface
* improved documentation
There is still a lot of things todo:
* add bulk test similar to Map that test operations on all the returned
collections from the interface
* the retrieval methods for a Key like get(Object) should never return a null
Collection, this would simplify the interface and one
can always safely operate on the returned result, e.g. get(key1).add(value);
* a MapIterator would make sense imho
* the Unmodifiable decorator is not yet fully unmodifiable, i.e. the result
returned by entries() can be modified
* add a SetValuedMap interface
* support also sorted maps
* add a Util class for factory methods to create various typical types of
MultiValuedMaps, e.g. a method
createArrayListValuedHashMap(), I would prefer this over specific types to
avoid bloat
* maybe add a Builder to easily create a MultiValuedMap by specifying the map
and collection type
* add a method asMap() to the interface which returns a Map view
* something else, but I forgot ...
@Transformed: if we allow transformers to other types we would break the
contract, so this is not possible right now. It is still possible by using raw
types, but this is a general problem affecting all collection types and should
thus be discussed separately.
Anyway, great work so far.
> 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, MultiValuedMap_2.patch,
> MultiValuedMap_3.patch, MultiValuedMap_4.patch,
> TransformedMultiValuedMap.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)
