On 11/15/2013 09:06 AM, Jörg Schaible wrote:
> Hi Thomas,
>
> Thomas Neidhart 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.
>
>
> We could introduce a compatibility interface and implement it like
>
> interface Java8Map {
> public boolean remove(Object key, Object value);
> }
>
> I wonder if it makes any problems for Java 8 though.
Does not really work and I would prefer the method renaming anyway as it
is more specific.
>> For the MultiKeyMap it would be semantically wrong too, thus I propose a
>> name change.
>
>
> The question is nevertheless, what does that method of Java 8 to
> MultiKeyMap? With Java 8 it simply exists.
>
>
>> For MultiMap:
>>
>> boolean removeMapping(K key, V value)
>
>
> If the method will do the same as Java 8 remove, we can stay with "remove"
> assuming the approach from above works.
>
>
>> 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.
>
>
> The question is anyway, if we should keep the overloaded method names. Since
> the inherited methods use "MultiKey<? extends K>" as key type in their
> signatures, we might as well introduce new names and provide vararg support,
> something like this:
>
> V putInto(V newVal, K... keys);
> V removeFrom(K... keys);
> V containsKeys(K... keys);
> ...
hmm, using varargs is not advised, as this will lead to warnings in
client side code, at least for Java 5.
There was an answer on the lambda-dev mailinglist, and the suggestion
was to change the methodname to removeKey(...), which would also be ok
for me (I suggested removeMultiKey, but this is more concise I guess).
If there would not be the problem with generics and varargs, I would be
in favor of changing all the methods in a similar way as you suggest,
but I fear this will make the situation just worse atm.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
