Maps and trivia questions : java generics
hanasaki
IDE. Anyone have comments of interest on the method "get" in the
interface as it pertains to proper use of Generics? JDK 1.6
I have an idea... Just bouncing it off the list blindly for a
confirmation / sanity check.
Thanks!
///////
package java.util;
import java.util.Map.Entry;
public interface Map<K extends Object, V extends Object> {
public static interface Entry<K extends Object, V extends Object> {
public K getKey();
public V getValue();
public V setValue(V v);
public boolean equals(Object o);
public int hashCode();
}
public int size();
public boolean isEmpty();
public boolean containsKey(Object o);
public boolean containsValue(Object o);
public V get(Object o);
public V put(K k, V v);
public V remove(Object o);
public void putAll(Map<? extends K, ? extends V> map);
public void clear();
public Set<K> keySet();
public Collection<V> values();
public Set<Entry<K, V>> entrySet();
public boolean equals(Object o);
public int hashCode();
}
hanasaki
get, containsKey and containsValue
--
=================================================================
= Management is doing things right; =
= Leadership is doing the right things. - Peter Drucker =
=================================================================
R Mac
Are u asking why the get method accepts arg of Object insted of
K? Please be more specific.
hanasaki
public boolean containsKey(Object o);
public V remove(Object o);
public boolean containsValue(Object o);
public V get(Object key)
vs
public boolean containsKey(K o);
public V remove(K o);
public boolean containsValue(V o);
public V get(K key)
On Oct 28, 12:38 pm, Ryan McCullough <rheag...@gmail.com> wrote:
> Are u asking why the get method accepts arg of Object instead of
>
Kevin Shekleton
I'm not really sure, but I'll bet that it is because the key compared by memory address, making it completely unnecessary, and possibly excessive to have a type definition. it might also save the compiler from needing to perform type erasure. If you are iterating over a keyList, then I could see why you would want to use generics. if you are iterating over a keyList that is of a type you have control of, and you really don't want to so something like Foo foo = (Foo)iter.next(); then you could possibly override the .equals() method to serve your purpose. of course you would only want to do this unless you are not isolating by memory address.
Ryan McCullough
Kevin Shekleton
please summarize your opinion, that thing has 4 different points of view
Ryan McCullough
(816) 2000-816 - Home & Mobile
David Mitchell
At least put a smiley down when you threaten to brand with the jerk iron.
Here is a quote for those of you viewing on a dial-up email only account:
<quote>
Uniformly, methods of the Java Collections Framework (and the Google Collections Library too) never restrict the types of their parameters except when it's necessary to prevent the collection from getting broken.
</quote>
--David
Please para-phrase your opinion in the email thread, or be brandeds a hard headed jerk. Not everyone here is able to view this link.
On Oct 29, 2009 10:25 PM, "Kevin Shekleton" <kevin.s...@gmail.com> wrote:
Take a look at the accepted answer, which also has the most up votes.
On Thu, Oct 29, 2009 at 5:32 PM, Ryan McCullough <rhea...@gmail.com> wrote: > > please summarize ...
luke w patterson
> Easy there!
>
> At least put a smiley down when you threaten to brand with the jerk iron.
>
http://gafter.blogspot.com/2006/11/reified-generics-for-java.html?showComment=1203883620000#c8374851026588442066
:) :)
michael
No one had mentioned it, so I'll chime in with Josh Bloch's recent
addition to his (growing) list of "Effective Java" tips, specifically
referring to Generics. Apropos, & might be of interest to some -- but
doesn't address the *specific* issue at hand (*).
There's a video & a set of slides to review. A few puzzlers are thrown
in for good measure.
* http://www.youtube.com/watch?v=V1vQf4qyMXg&fmt=22
* http://files.meetup.com/1381525/still-effective.ppt.pdf
Specifically, to summarize, the recommendation regards parameters to
methods (nb: don't use wildcard types as return types). He categorizes
a method parameter as either a "producer" (giving data to the method)
or "consumer" (the method inserts things into the argument).
Consider a "Stack" class with methods: pushAll(Collection src) and
popAll(Collection target).
As per Josh, remember "PECS": "Producer extends, Consumer
super" (...not sure if that helps, but...)
* For a T producer, use Foo<? extends T>
* For a T consumer, use Foo<? super T>
Say you had the aforementioned Stack w/ bulk add (push) and get (pop)
methods. Instead of this:
void pushAll(Collection<E> src); // producer, src is read from
void popAll(Collection<E> dst); // consumer, dst is populated
You'd use:
void pushAll(Collection<? extends E> src);
void popAll(Collection<? super E> dst);
If there's a method that takes as an argument something that is both a
producer and a consumer, then you'd just have to use Collection<E>
(...the intersection of <? extends E> and <? super E>). If the
argument is neither a producer nor a consumer (e.g., a functor?) then
you don't care what type it is: use Foo<?>. (Note that I had been
using a "Collection" just to follow the example from above; I could
just as easily used "Foo" all over the place. The "producer" and
"consumer" analogy works better with a collection.)
The talk also includes more "effective" tips on: enum types, varargs,
concurrency, and [more] on serialization.
And, for something perhaps new to any old patterns wonks out there (I
know, not trendy anymore, unless you make them in the Cloud or
something): check out the "Typesafe Heterogeneous Container
Pattern" (idiom?) from the talk and/or slides (or google it, for a
more complete treatment).
-michael
(*) i.e., "Schrödinger's Key". When in the map, it's simultaneously
two types at once: the type you put in, and the type you *will* use
when calling "get(Object)" (et al.).
On Oct 28, 9:25 am, hanasaki <hanas...@hanaden.com> wrote:
> Below is the code from interface java.util.Map pulled from my favorite
> IDE. Anyone have comments of interest on the method "get" in the
> interface as it pertains to proper use of Generics? JDK 1.6
>
> I have an idea... Just bouncing it off the list blindly for a
> confirmation / sanity check.
>
> Thanks!
>
> ///////
>
> package java.util;
>
> import java.util.Map.Entry;
>
> public interface Map<K extends Object, V extends Object> {
> public boolean containsValue(Object o);
> public V get(Object o);
> public V put(K k, V v);
> public V remove(Object o);
> public void putAll(Map<? extends K, ? extends V> map);
...
> }