[
https://issues.apache.org/jira/browse/COLLECTIONS-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13947713#comment-13947713
]
Dipanjan Laha commented on COLLECTIONS-508:
-------------------------------------------
Thanks Thomas. It's great to see the first version committed :)
I will pick up the following and work on those for now
{quote}
add bulk test similar to Map that test operations on all the returned
collections from the interface
{quote}
- I will add these
{quote}
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);
{quote}
- I did think about this, but there is one problem here. For every get with
non existent keys, we would need to add a mapping with an empty collection and
return that. Otherwise get(key1).add(value) would add the value in the
collection, but the collection would not be there in the map. I am not sure
whether this behavior of adding an empty Collection in the map for each get
with non-existent key is acceptable. Or, it just occurred to me just now that
in case of non existent keys, we can return a custom implementation of
Collection which has a reference to the map and the key, and would add itself
as a mapping when add(value) is called on it. let me know what you think? I'll
implement accordingly.
- I will add a MapIterator
{quote}
the Unmodifiable decorator is not yet fully unmodifiable, i.e. the result
returned by entries() can be modified
{quote}
- The Entry elements in the entries() collection is inherently Unmodifiable i.e
Entry.setValue(val) (in AbstractMultiValuedMap) throws
UnsupportedOperationException. This is so because imho the setValue for an
entry of MultiValuedMap does not make sense as the original mapping is actually
a collection. I have also wrapped the entries collections in an
UnmodifiableCollection while returning from UnmodifiableMultiValedMap. Let me
know if I have missed a gap which is making it modifiable. Also, let me know if
you feel differently about the Entry of a MultiValuedMap being inherently
unmodifiable, maybe the setValue should replace all the occurrences of the
original value in the mapped Collection.
- I will add SetValuedMap. Are you thinking of factory methods in the
MultiValuedMap's implementations (say MultiValuedHashMap) to return
ListValuedMap and SetValuedMap or would you have these in the Util class you
mentioned?
- I will work on a SortedMap implementation. I might have some questions around
this, I'll ask you once I sit with it.
- I will add an asMap() method.
I can pick up more stuff once I am done with these. And if by any chance you
use eclipse, can you share your code format settings(exported from excel). I
saw that the checked in code had a slightly different code style and I would
like to confirm to it. That way you won't have to check the code style for each
and every patch I submit.
> 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)
