[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] [Updated] (COLLECTIONS-508) MultiMap's methods are not strongly typed even though the interfa
From:       "Dipanjan Laha (JIRA)" <jira () apache ! org>
Date:       2014-03-30 15:48:14
Message-ID: JIRA.12696788.1393155255475.33366.1396194494582 () arcas
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/COLLECTIONS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Dipanjan Laha updated COLLECTIONS-508:
--------------------------------------

    Attachment: MultiValuedMap_5.patch

I have worked on a few things I had mentioned and created another patch over your \
                last commit (MultiValuedMap_5). This patch contains the following
- Tests for collections returned by UnmodifiableMultiValuedMap to test the \
                unmodifiable behavior 
- Bulk Test for all the collections returned from the map
- While adding the BulkTests, I found certain issue within the AbstractMultiValuedMap \
                and I fixed them
- Also, while adding the Bulk tests, I found an issue with AbstractCollectionTest's \
testCollectionRemoveAll methods. The sublist call with min and max calculations on \
getFullElements() returns empty when the getFullElements size is 3. I have fixed \
                that.
- Added a asMap method and associated tests.
- Added a mapIterator() and tests.

I have not touched the get behavior yet as imo a proper consensus has not been \
reached on the mailing list. Let me know which approach to follow and I will make the \
appropriate changes. 

I am not working on the sorted map now as suggested by you. I will take up the other \
items you had mentioned and work on them.

> 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, MultiValuedMap_5.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)


[prev in list] [next in list] [prev in thread] [next in thread]