Prev: Java crash
Next: NullPointerException
From: markspace on 24 Feb 2010 13:15
Roedy Green wrote:
> On 24 Feb 2010 12:49:17 GMT, Thomas Pornin <pornin(a)bolet.org> wrote,
> quoted or indirectly quoted someone who said :
>
>> In your situation, you have to
>> "know" which instances of Comparable can be compared to each other and
>> which cannot.
>
> In the old days, so long as each column contained compatible things,
> you could just use Comparable.compareTo and all would automagically
> sort itself out. Today you get squawking if you do it because, for
> example, String no longer implements Comparable, it implements
> Comparable<String> which will not cast to Comparable or
> Comparable<Object>


I'm pretty sure String will cast to Comparable<String>.
From: Lew on 24 Feb 2010 13:24
Thomas Pornin <pornin(a)bolet.org> wrote, quoted or indirectly quoted someone
who said :
>>> In your situation, you have to
>>> "know" which instances of Comparable can be compared to each other and
>>> which cannot.

Roedy Green wrote:
>> In the old days, so long as each column contained compatible things,
>> you could just use Comparable.compareTo and all would automagically
>> sort itself out. Today you get squawking if you do it because, for
>> example, String no longer implements Comparable, it implements
>> Comparable<String> which will not cast to Comparable or
>> Comparable<Object>

markspace wrote:
> I'm pretty sure String will cast to Comparable<String>.

Of course it will. I don't know where the notion comes from that 'String'
does not implement 'Comparable<String>', when it says right in the Javadocs
that it does.

And the requirement that generics impose that you specify what ensures that a
column "contained compatible things" is the key. Roedy waves a magic wand
with that offhand phrase, but the whole point of generics is to make that a
compile-time check, instead of a run-time check in "the old days". "All" did
not "automagically sort itself out" because if you violated that "so long as"
condition via a bug or other means, you'd get a weird results. I mean, what
if you put an Float and a Double, say, into the same column in "the old days"?
What would happen?

With generics you'd know that at compile time and avoid an expensive,
embarrassing bug. That's the thing that makes the "new days" so much better.

--
Lew
From: Mike Schilling on 24 Feb 2010 15:28

"markspace" <nospam(a)nowhere.com> wrote in message
news:hm3qcf$c4b$3(a)news.eternal-september.org...
> Roedy Green wrote:
>> On 24 Feb 2010 12:49:17 GMT, Thomas Pornin <pornin(a)bolet.org> wrote,
>> quoted or indirectly quoted someone who said :
>>
>>> In your situation, you have to
>>> "know" which instances of Comparable can be compared to each other and
>>> which cannot.
>>
>> In the old days, so long as each column contained compatible things,
>> you could just use Comparable.compareTo and all would automagically
>> sort itself out. Today you get squawking if you do it because, for
>> example, String no longer implements Comparable, it implements
>> Comparable<String> which will not cast to Comparable or
>> Comparable<Object>
>
>
> I'm pretty sure String will cast to Comparable<String>.

At worst, you can always use the universal Comparator:

public class Comparer implements Comparator<Comparable <?>>
{
public int compare(Comparable<?> o1, Comparable<?> o2)
{
Comparable<Object> oo1 = (Comparable<Object>) o1;
return oo1.compareTo(o2);
}
}

This acts exactly like Java 1.4: it will compare any two objects, quite
possibly leading to a runtime exception.


From: Daniel Pitts on 24 Feb 2010 19:47
On 2/23/2010 11:50 PM, Roedy Green wrote:
> If Comparable were just an ordinary interface you could say things
> like this:
>
> Comparable a = "abc";
> Comparable b = Double.valueOf ( 10.0d );
> Comparable c = Double.valueOf ( 12.9d );
>
>
> int x = b.compareTo( c );
>
> But generics butt in and it seems to be impossible to keep around
> arrays of Comparables for sorting columns.
Well, you wouldn't want to keep any kind of arrays around, use List<Foo>
or Collection<Foo> instead...

Now, if you have a generic sortable container, you would use
MyContainer<T extends Comparable<T>> as the declared type, so that you
could have StringColumn implements MyContainer<String>.


>
> One way, which I find ugly is to sort Objects instead of Comparables
> then cast them to specific types before calling compareTo. That should
> not be necessary. All the JVM should need to know at compile time is
> that a reference is implements comparable.
Yes, but at compile time, wouldn't you prefer avoiding
ClassCastException from within compareTo?

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Lew on 25 Feb 2010 00:15
Roedy Green wrote:
>>> In the old days, so long as each column contained compatible things,
>>> you could just use Comparable.compareTo and all would automagically
>>> sort itself out. Today you get squawking if you do it because, for
>>> example, String no longer implements Comparable, it implements
>>> Comparable<String> which will not cast to Comparable or
>>> Comparable<Object>

Mike Schilling wrote:
> At worst, you can always use the universal Comparator:
>
> public class Comparer implements Comparator<Comparable <?>>
> {
> public int compare(Comparable<?> o1, Comparable<?> o2)
> {
> Comparable<Object> oo1 = (Comparable<Object>) o1;
> return oo1.compareTo(o2);
> }
> }
>
> This acts exactly like Java 1.4: it will compare any two objects, quite
> possibly leading to a runtime exception.

Now these are the good old days!

--
Lew
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Java crash
Next: NullPointerException