On Wed, Feb 15, 2012 at 12:44 PM, Matt Benson <gudnabr...@gmail.com> wrote: > On Wed, Feb 15, 2012 at 2:35 PM, Jörg Schaible <joerg.schai...@gmx.de> wrote: >> Hi Benedict, >> >> Benedikt Ritter wrote: >> >>> Hi, >>> >>> finally I've found the time to answer to this topic :) We had a similar >>> discussion a while ago [1]. Back then James suggested to drop >>> collections completely in favor of google guava. I have started to >>> implement QueryableCollections in trunk anyway, because I still disagree >>> with James. >>> I would appreciate comments from one of commons collections commiters, >>> if they would like to have something like that. I still think, that the >>> possibility to query for elements would be a nice addition to collections. >>> >>> ATM I'm having some problems with the latest source: >>> Name clash: The method get(K) of type MultiMap<K,V> has the same erasure >>> as get(Object) of type Get<K,V> but does not override it >>> >>> Does anyone know something about that? >> >> That's a very unfortunate signature from the JDK interface and all I can >> guess, why it defines Object as argument, is for compatibility reasons. If >> we derive from the JDK interface, you cannot declare "get(K)", only >> "get(Object)". > > Actually, I approve of get(Object). No reason to stop Map clients > from checking whether a given object is in the map, even if it never > can be.
Why not just get rid of generics and go back to adding casts everywhere? After all, there's no point of generics in Java except as a safety measure at compile time. get only returns Object for backwards compatibility reasons and it's a pain in the ass. > Matt Regards, James --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
