[
https://issues.apache.org/jira/browse/COLLECTIONS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13948565#comment-13948565
]
Thomas Neidhart commented on COLLECTIONS-508:
---------------------------------------------
@get(Object): this was just an idea after looking at the Mulitmap interface of
guava. The returned collection would need to be added immediately to avoid
undefined behavior when calling get(Object) twice before adding an value. I do
not like the fact that containsKey would return something else after get has
been called, but never returning null also has benefits. Maybe we should
discuss this on the mailinglist
@Unmodifiable: you are right, I did not check the actual collection returned by
entries(), so this should be correct, but we need to add tests to check that
the returned collections are indeed unmodifiable
@SortedMap: maybe we should postpone this to later and first focus on making
the existing things complete
@formatter: I do not use a specific formatter for this project due to the
inherited codestyle, but I have checkstyle enabled, using the rules in
src/conf/checkstyle.xml
> 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)
