Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34716 > unrolled thread

mollifying generics

Back to article view | Back to comp.lang.java.programmer

Contents

  mollifying generics Roedy Green <inquiry@mindprod.com> - 2016-06-29 01:11 -0700
    Re: mollifying generics Andreas Leitgeb <avl@logic.at> - 2016-06-29 08:33 +0000
    Re: mollifying generics Daniel Pitts <usenet@coloraura.com> - 2016-06-29 13:43 -0700
      Re: mollifying generics Daniel Pitts <usenet@coloraura.com> - 2016-06-29 13:47 -0700
    Re: mollifying generics Arne Vajhøj <arne@vajhoej.dk> - 2016-07-05 22:28 -0400

#34716 — mollifying generics

Prior to generics, I could say something like this:

Comparable a = "abc";
Comparable b = "def";

or Comparable a = new Long( 2 );
Comparable b = new Long ( 4 );


int diff = a.compareTo(b);

The run time would use the corresponding compareTo method

Now generics complains about an unchecked operation.

Is there a way to mollify it?  I have tried what I thought were the
obvious means.

[toc] | [next] | [standalone]

#34718

Roedy Green <inquiry@mindprod.com> wrote:
> Now generics complains about an unchecked operation.
> Is there a way to mollify it?  
> I have tried what I thought were the
> obvious means.

Most cases would just add a proper parameterization to Comparable
or even replace Comparable with some parameter type altogether.

If nothing else works, then use @SuppressWarnings annotation.

[toc] | [prev] | [next] | [standalone]

#34722

On 6/29/16 1:11 AM, Roedy Green wrote:
>
> Prior to generics, I could say something like this:
>
> Comparable a = "abc";
> Comparable b = "def";
>
> or Comparable a = new Long( 2 );
> Comparable b = new Long ( 4 );
>
>
> int diff = a.compareTo(b);
>
> The run time would use the corresponding compareTo method
>
> Now generics complains about an unchecked operation.
>
> Is there a way to mollify it?  I have tried what I thought were the
> obvious means.
>

Let's say you used to have this:


public void doSomethingWithDiff(Comparable a, Comparable b)
{
    int diff = a.compareTo(b);
    if (diff < 0) {
       handleLess();
    } else if (diff > 0) {
       handleMore();
    } else {
       handleEqual();
    }
}

You would want to replace it with:
     public <T> void doSomethingWithDiff(Comparable<T> a, T b)

Or:
   public <T extends Comparable<? super T>> void doSomethingWithDiff(T 
a, T b)

Either one of those will work as a type safe alternative.

You'll have to keep track of the type with generics *or* specifics up to 
that point to have the compiler satisfied.

[toc] | [prev] | [next] | [standalone]

#34723

On 6/29/16 1:43 PM, Daniel Pitts wrote:
> On 6/29/16 1:11 AM, Roedy Green wrote:
>>
>> Prior to generics, I could say something like this:
>>
>> Comparable a = "abc";
>> Comparable b = "def";
>>
>> or Comparable a = new Long( 2 );
>> Comparable b = new Long ( 4 );
>>
>>
>> int diff = a.compareTo(b);
>>
>> The run time would use the corresponding compareTo method
>>
>> Now generics complains about an unchecked operation.
>>
>> Is there a way to mollify it?  I have tried what I thought were the
>> obvious means.
>>
>
> Let's say you used to have this:
>
>
> public void doSomethingWithDiff(Comparable a, Comparable b)
> {
>    int diff = a.compareTo(b);
>    if (diff < 0) {
>       handleLess();
>    } else if (diff > 0) {
>       handleMore();
>    } else {
>       handleEqual();
>    }
> }
>
> You would want to replace it with:
>     public <T> void doSomethingWithDiff(Comparable<T> a, T b)
>
> Or:
>   public <T extends Comparable<? super T>> void doSomethingWithDiff(T a,
> T b)
>
> Either one of those will work as a type safe alternative.
>
> You'll have to keep track of the type with generics *or* specifics up to
> that point to have the compiler satisfied.
>
>

You could also more easily not keep track of the type in your client 
code, and move that into a separate class:

public class ComparablePair<T extends Comparable<? super T>> {
     private final T left;
     private final T right;

     public ComparablePair(T left, T right) {
         this.left = left;
         this.right = right;
     }

     public int compare() {
         return left.compareTo(right);
     }
}

You could use it then:

ComparablePair<?> pair
     = new ComparablePair<>("abc", "def");

ComparablePair<?> anotherPair
     = new ComparablePair<>(new Long(2), new Long(4));

[toc] | [prev] | [next] | [standalone]

#34763

On 6/29/2016 4:11 AM, Roedy Green wrote:
> Prior to generics, I could say something like this:
>
> Comparable a = "abc";
> Comparable b = "def";
>
> or Comparable a = new Long( 2 );
> Comparable b = new Long ( 4 );
>
>
> int diff = a.compareTo(b);
>
> The run time would use the corresponding compareTo method
>
> Now generics complains about an unchecked operation.

Yes.

And that is good.

The old code is not type safe.

public class ToComOrNotToComp {
	public static void main(String[] args) {
		Comparable a = "abc";
		Comparable b = "def";
		System.out.println(a.compareTo(b));
		Comparable c = new Long(2);
		Comparable d = new Long(4);
		System.out.println(c.compareTo(d));
		System.out.println(a.compareTo(d));
	}
}

gives 7 warning, but also an exception at runtime.

> Is there a way to mollify it?  I have tried what I thought were the
> obvious means.

I don't think there are any good solution, because I don't think
there should be a good solution.

A Comparable<X> can be compared to a X.

But I don't think one can assume that a Comparable<X> can be
compared to a Comparable<X>.

Or to rephrase it: your assignments are losing too much
information to make comparison feasible.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web