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 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);
hanasaki 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 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(); > }
--
================================================================= = Management is doing things right; = = Leadership is doing the right things. - Peter Drucker = =================================================================
Are u asking why the get method accepts arg of Object insted of
K? Please be more specific.
On Oct 28, 2009 12:25 PM, "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 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);
> Are u asking why the get method accepts arg of Object instead of
> K? Please be more specific.
> On Oct 28, 2009 12:25 PM, "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 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);
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.
On Wed, Oct 28, 2009 at 10:32 PM, hanasaki <hanas...@gmail.com> wrote:
> Bingo. Your thoughts?
> 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
> > K? Please be more specific.
> > On Oct 28, 2009 12:25 PM, "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 static interface Entry<K extends Object, V extends Object> {
> 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
> On Wed, Oct 28, 2009 at 10:32 PM, hanasaki <hanas...@gmail.com> wrote:
>> Bingo. Your thoughts?
>> 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
>> > K? Please be more specific.
>> > On Oct 28, 2009 12:25 PM, "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 static interface Entry<K extends Object, V extends Object> {
> On Wed, Oct 28, 2009 at 10:46 PM, Ryan McCullough <rheag...@gmail.com>wrote:
>> 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
>> On Wed, Oct 28, 2009 at 10:32 PM, hanasaki <hanas...@gmail.com> wrote:
>>> Bingo. Your thoughts?
>>> 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
>>> > K? Please be more specific.
>>> > On Oct 28, 2009 12:25 PM, "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 static interface Entry<K extends Object, V extends Object> {
On Thu, Oct 29, 2009 at 5:32 PM, Ryan McCullough <rheag...@gmail.com> wrote:
> please summarize your opinion, that thing has 4 different points of view
> Ryan McCullough
> (816) 2000-816 - Home & Mobile
> On Thu, Oct 29, 2009 at 5:14 PM, Kevin Shekleton <
> kevin.shekle...@gmail.com> wrote:
>> This came up between a colleague and myself and here's StackOverflow to
>> the rescue:
>> On Wed, Oct 28, 2009 at 10:46 PM, Ryan McCullough <rheag...@gmail.com>wrote:
>>> 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
>>> On Wed, Oct 28, 2009 at 10:32 PM, hanasaki <hanas...@gmail.com> wrote:
>>>> Bingo. Your thoughts?
>>>> 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
>>>> > K? Please be more specific.
>>>> > On Oct 28, 2009 12:25 PM, "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 static interface Entry<K extends Object, V extends Object>
>>>> {
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
On Thu, Oct 29, 2009 at 10:58 PM, Ryan McCullough <rheag...@gmail.com>wrote:
> 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
> On Thu, Oct 29, 2009 at 10:58 PM, Ryan McCullough <rheag...@gmail.com>wrote:
>> 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.shekle...@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 <rheag...@gmail.com>
>> wrote: > > please summarize ...
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 (*).
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
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 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 boolean equals(Object o);
...
> }
|
