For anyone's observation, I sent this question to the Open JDK list because I am so surprised how adding default methods can break custom interface extensions. I was really hoping default methods would be much more subtle but it turns out this could be a common occurrence going forward. What if JDK 9 introduces new default methods with other clashes to us? I ask rhetorically but I think you can see my point.
On Thu, Nov 14, 2013 at 4:36 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 11/14/13 1:06 PM, Thomas Neidhart wrote: > > 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 > > For MultiMap, shouldn't it also be "removeValue" if we go that way, > since what is being removed (IIUC) is one of the values in the > collection that is the entry? > > > > 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? > > Your proposal on that looks good to me. I am ambivalent on > removeValue, removeEntry, removeMapping, slightly favoring the last > (your original proposal). > > I agree with your recommendation on return values. > > Phil > > > > Thomas > > > >> Gary > >> > >> > >> On Wed, Nov 13, 2013 at 4:49 PM, Thomas Neidhart > >> <thomas.neidh...@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-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Cheers, Paul
