Sorting TimeZone

Lew wrote :
> Lew wrote :
>>> 'TimeZone' can easily be a map key, yes, even for a 'TreeMap'.
>>
>
> Wojtek wrote:
>> No it cannot be used as a key. It does not have a 'compareTo' method.
>>
>
> Yes, it can be used as a key!
> <http://java.sun.com/javase/6/docs/ap...p.html#TreeMap
> (java.util.Comparator)>
>
> The Javadocs are your friend.

Yes with a separate Comparator. However you cannot do:

TreeMap<TimeZone,String>

directly.

--
Wojtek

Wojtek

Lew wrote :
>>>> 'TimeZone' can easily be a map key, yes, even for a 'TreeMap'.
>

Wojtek wrote:
> >> No it cannot be used as a key. It does not have a 'compareTo' method.
>

Lew wrote:
>> Yes, it can be used as a key!
>> <http://java.sun.com/javase/6/docs/ap...p.html#TreeMap
>> (java.util.Comparator)>
>
>> The Javadocs are your friend.
>

Wojtek wrote:
> Yes with a separate Comparator. However you cannot do:
>
> TreeMap<TimeZone,String>
>
> directly.
>

Why doesn't

Map <TimeZone, String> map =
new TreeMap <TimeZone, String> ( new Comparator() { .... } );

work for you?

--
Lew

Lew

Lew wrote:
> Why doesn't
>
> * Map <TimeZone, String> map =
> * * new TreeMap <TimeZone, String> ( new Comparator() { .... } );
>
> work for you?

Oops. Naturally I meant to write

Map <TimeZone, String> map =
new TreeMap <TimeZone, String> ( new Comparator <TimeZone> ()
{ .... } );

--
Lew

Lew

Lew wrote :
> Lew wrote:
>
> Oops. Naturally I meant to write
>
> Map <TimeZone, String> map =
> new TreeMap <TimeZone, String> ( new Comparator <TimeZone> ()
> { .... } );

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:

Map <TimeZone, String> map = new TreeMap <TimeZone, String>();

Which of course fails during runtime.

--
Wojtek

Wojtek

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.

Patricia Shanahan wrote:
> The natural order and comparator behaviors are equally valid. Throughout
> the TreeMap documentation, unqualified statements apply to both cases.
> Statements that only apply to the natural order case say so. Given the
> way the TreeMap documentation is written, I would not assume a natural
> order TreeMap is meant unless the writer says so.
>

In this case, the writer did explicitly mention use of a custom
Comparator.

> I think it is a mistake to treat a Comparable key type as the proper way
> to use TreeMap or TreeSet, and a specified Comparator as somehow weird
> or "indirect". It can create a mental block to what is often the best
> choice for a sorted set or sorted map implementation, when either the
> key type does not implement Comparable, or the required order is not its
> Comparable order.
>

What she said, especially since I had actually referred to a custom
Comparator in my post, and others had also chimed in with that same
suggestion, including Wojtek himself! Pretending that that was not
evident smacks of deliberate obtuseness.

--
Lew

Lew

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>.

For a Comparator, the signature is Comparator<T> where the 'T' refers
to a 'Type':
http://www.j2ee.me/javase/6/docs/api...omparator.html

--
Wojtek

Wojtek

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...omparator.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.

--
Wojtek

Wojtek

Wojtek wrote :
> 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).

Ah sorry, it was a break statement:
http://users.csc.calpoly.edu/~jdalbe..._collapse.html

--
Wojtek

Wojtek

Wojtek wrote:
> Semantics!

The word "semantics" means "meaning", so it isn't trivial.

> 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 [sic].

Now I see where your difficulty lies and I'm much more sympathetic to your cause.

In both contexts the type parameter signifies a type. In 'Map <K, V>' there
are two type parameters, indicating the types to which the Map is bound. The
first is the type of the key, and the second is the type of the value.

There is no semantic difference between expressing that as 'Map <K, V>',
'Map <T, U>' or even 'Map <foo, bar>'.

> Otherwise the Javadoc author would not have made that distinction.

There is no distinction. The choice of letters in the Javadocs is arbitrary
and designed to help us understand the usage of the two types managed by the
'Map', but regardless a type parameter is a type parameter is a type parameter.

> 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.

That is not true. Take a look again at the Javadocs for 'TreeMap' to which I
pointed you earlier:

<http://java.sun.com/javase/6/docs/api/java/util/TreeMap.html#TreeMap(java.util.Comparator)>

Note that they describe the comparator type parameter as '<? super K>' - that
is the exact same 'K' as in the 'TreeMap <K, V>' type parameter.

For further understanding, check out the rules for type parameters in the JLS.

--
Lew

Lew

Wojtek wrote:
>> 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.

Lew wrote:
> That is not true. Take a look again at the Javadocs for 'TreeMap' to
> which I pointed you earlier:
>
> <http://java.sun.com/javase/6/docs/api/java/util/TreeMap.html#TreeMap(java.util.Comparator)>
>
> Note that they describe the comparator type parameter as '<? super K>' -
> that is the exact same 'K' as in the 'TreeMap <K, V>' type parameter.

I was unclear, in part because your antecedents are hazy. It is true that a
'TreeMap' that uses "natural" order does not need a 'Comparator' and that one
that needs a 'Comparator' does need a 'Comparator'. It is not true that the
type parameter 'K' in 'TreeMap <K, V>' is different from the type parameter
'K' in the 'TreeMap' constructor argument 'Comparator <? super K>'.

--
Lew

Lew