commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dipanjan Laha <dipanja...@gmail.com>
Subject Re: [collections] Issues with MultiMap generics and need of a MultiTrie
Date Wed, 26 Feb 2014 08:28:07 GMT
Hi Thomas,

It would be great if we can start the discussion on the new interface for
MultiMap and a new package for the implementations as suggested by you.
Then I'll be able to put some code together for the same.

IMO we can have

1. New Interface for MultiMap with the name MultiValuedMap or MultiValMap
 (as MultiValueMap is already the existing implementing class).
2. New package for the implementations:
org.apache.commons.collections.multimap or
org.apache.commons.collections.multivaluedmap
3. Implementation names like : MultiValuedHashMap, MultiValuedTreeMap etc

Please let me know of your thoughts on these.

Regards
Dipanjan

On Sun, Feb 23, 2014 at 8:36 PM, Dipanjan Laha <dipanjan21@gmail.com> wrote:

> Hi Thomas,
>
> Thanks for your feedback. I created an improvement request in Jira for the
> same (https://issues.apache.org/jira/browse/COLLECTIONS-508 ) as I
> thought it could be better tracked there. Sorry for the duplication in the
> mail list and Jira. I have also attached a patch in Jira where I have
> modified the existing MultiMap interface and the MultiValueMap
> implementation and their test cases. I agree that it would break backward
> compatibility and we should go with your suggestion of deprecating the
> existing ones and design fresh interfaces for the same. The patch is just a
> sample implementation to demonstrate the issue and is far from being
> complete in terms of documentation and test cases. I am also attaching the
> patch here for your reference.
>
> Please go through the patch and also let me know of your thoughts on how
> we should proceed with the new interface and package structure. I'll be
> happy to change and redirect the implementation as per your suggestion. I
> am new to Apache Commons, but with some guidance I should not have issues
> implementing them to start with.
>
> As for MultiTrie, as you mentioned, we can start with it once the new
> MultiMap has been finalized.
>
> Regards
> Dipanjan
>
>
>
>
> On Sun, Feb 23, 2014 at 6:09 PM, Thomas Neidhart <
> thomas.neidhart@gmail.com> wrote:
>
>> On 02/22/2014 02:00 PM, Dipanjan Laha wrote:
>> > Hello,
>>
>> Hi Dipanjan,
>>
>> > Recently I had the need of using a MultiMap in one of my projects. I
>> found
>> > that commons collection already has a MultiMap interface and an
>> > implementation.
>> >
>> > 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 extending 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.
>>
>> The MultiMap interface as it is right now is flawed, and should have
>> been cleaned up prior to the 4.0 release imho (and I regretted it
>> already before your post).
>>
>> As you correctly pointed out, the problem comes from the fact that it
>> extends Map<K, Object> which leads to problems once generics have been
>> introduced (before it did not matter that much as you had to cast
>> anyway, as it is also documented in the javadoc).
>>
>> One mitigation for this was the introduction of this method to
>> MultiValueMap, but it is clearly not enough:
>>
>>  public Collection<V> getCollection(Object key)
>>
>>
>> Unfortunately, it is not easy to fix this now after collections 4.0 has
>> been released. We need to keep backwards compatibility, but we could do
>> the following:
>>
>>  * deprecate the existing interfaces/classes:
>>    - MultiMap
>>    - MultiValueMap
>>
>>  * design a new, clean interface (by not extending Map)
>>  * add new package multimap with concrete implementations for different
>>    types of maps (right now only hashmaps are supported)
>>
>> > Please let me know your thoughts on this. I can submit a patch for these
>> > changes based on your feedback. One more thing, I also am in need of a
>> > MultiTrie which is currently not there. I am implementing the same by
>> > wrapping PatriciaTrie. Now I am a bit confused here as, if I make the
>> > MultiTrie interface on the lines of MultiMap, it would have the same
>> > limitations. In that case I was planning to have a separate set of
>> > interfaces for MultiTrie which does not extend any other interface. And
>> in
>> > case, we do change the MultiMap interface to be independent of Map, then
>> > MultiTrie can extend MultiMap. Please let me know your thoughts on this
>> as
>> > well as I am implementing the same for my project right now and would
>> like
>> > to contribute it back to the commons collection.
>>
>> Patches are always welcome, but we first need a decision in which
>> direction to go, see above.
>>
>> Regarding the MultiTrie:
>>
>> Indeed, it is the same problem, so it should go hand in hand with the
>> revamp of the MultiMap interface.
>>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message