commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: [collections] MultiMap clash with Java 8
Date Thu, 14 Nov 2013 21:06:56 GMT
On 11/14/2013 06:12 AM, Gary Gregory wrote:
> How about the name removeEntry|Entries since there is a Map.Entry.

Also possible, but there is a subtle difference imho:

 * removeMapping does not assume that such a mapping exists, whereas
 * removeEntry sounds like you remove an entry that you are sure exists

The method may not succeed, as there is no such mapping currently in the
map.

But I would be fine with removeEntry too.
What about the methods for MultiKeyMap? Any comments?

Thomas

> 
> Gary
> 
> 
> On Wed, Nov 13, 2013 at 4:49 PM, Thomas Neidhart
> <thomas.neidhart@gmail.com>wrote:
> 
>> Hi,
>>
>> during the vote for collections 4.0 we have discovered a problem wrt the
>> MultiMap interface in general and specifically the MultiKeyMap.
>>
>> Java 8 introduces a new default method in the Map interface:
>>
>>  boolean remove(Object key, Object value)
>>
>> This clashes with the method in MultiMap:
>>
>>  V remove(K key, V value)
>>
>> and the remove methods for multiple keys in MultiKeyMap:
>>
>>  V remove(K key1, K key2)
>>
>>
>> Just changing the return type does not solve the problem, as one can not
>> re-define a method in an interface without using the @Override
>> annotation, but this would only work when compiling with JDK 8 and fail
>> for other JDKs.
>>
>> For the MultiKeyMap it would be semantically wrong too, thus I propose a
>> name change.
>>
>> For MultiMap:
>>
>>  boolean removeMapping(K key, V value)
>>
>> For MultiKeyMap (for all remove(K ...) methods):
>>
>>  V removeMultiKey(K key1, K key2)
>>  V removeMultiKey(K key1, K key2, K key3)
>>  ...
>>
>>
>> In the case of the MultiMap, I think returning a boolean makes more
>> sense, similar as Java 8 does it.
>>
>> For the MultiKeyMap, returning the previously mapped value is preferable
>> imho.
>>
>> Any objections?
>>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message