From: Lew on
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

From: Wojtek on
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 :-)


From: Patricia Shanahan on
Wojtek wrote:
> 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:

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.

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.

Patricia
From: Lew on
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
From: Wojtek on
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/java/util/Comparator.html

--
Wojtek :-)