On 11/14/13 2:39 PM, Paul Benedict wrote: > 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.
Yes, this is a good point. On the other hand, whenever you add to an interface you risk this. The likelihood of this happening is greater with less precise method names in the extensions. We are looking at a great example here: "remove" in our classes should arguably have been made more precise in the first place. Independent of the name clash problem, I think Thomas' recommendations represent an improvement. Phil > > > 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
