Eric Sosman wrote :
Wojtek wrote:
Lew wrote :
Lew wrote :
Map <TimeZone, String> map =
new TreeMap <TimeZone, String> ( new Comparator <TimeZone> ()
{ .... } );
Wojtek wrote:
No arguments that this does work.
However I was replying to your statement "'TimeZone' can easily be
a map
key, yes, even for a 'TreeMap'. " which appears to say that you do
not
need a custom Comparator:
Even though I had explicitly mentioned a custom Comparator in the post
to which you were replying? Come on, now. Your explanation is
disingenuous at best.
To me a 'key' is the part which goes into the 'K' part of Map<K,V>.
Yes, that's right.
For a Comparator, the signature is Comparator<T> where the 'T' refers
to a 'Type':
http://www.j2ee.me/javase/6/docs/api/java/util/Comparator.html
... which means only that the K in Map<K,V> is the same as
the T in Comparator<T>, or is a subclass/subinterface of T. You
shouldn't read too much into the particular letters chosen to name
type parameters; the names are as arbitrary as those of method
parameters, and carry no deeper meaning.
Does Map<String,String> bother you, because String == String
but K != V? If not, K != T shouldn't bother you, either, even if
you have a Map<Book,Date> and a Comparator<Book> with Book == Book.
Semantics!
We work in a precise field. An extra semi-colon can make a world of
difference (brought down a phone system a few years ago).
So yes, the labelling DOES make a difference. Whereas a Book is a Book,
where it is used does change its meaning. So in Map<Book,Date>, Book is
a key and in Comparator<Book>, Book is a Type.
Otherwise the Javadoc author would not have made that distinction.
It is used differently. As a key, it must provide its own comparison
methodology. As a type, the Comparator makes the comparison, possibly
using an external conversion such as I18N.
I've encountered before. And, as mentioned before, that you attach
formal parameter. <Shrug.>