Question about Generics

[Danno]

I think the idea of generics is that your code should be "generic". In
other words, while IntRange is fine for a class, generics force to be
more generic in your approach, so I created a regular class called
Range. I provided an example below, using your code, that seems to
work ok. I included a main method so you can check it out using longs,
short, etc.

I am no badass with generics, I just know the regular stuff. You just
happened to post while I was researching some advanced uses for
generics.

Let me know if that works for ya through here or email.

package com.evolutionnext;

import java.util.TreeSet;

/**
*
* @author valued customer
*/
public class Range<E extends Comparable<E>> extends TreeSet<E>{
public Range(E first, E second) {
add(first);
add(second);
}

public Range(E[] range) {
if (range.length != 2) {
throw new IllegalArgumentException("The Range array must
have exactly two values.");
}
add(range[0]);
add(range[1]);
}

public boolean input(E element) {
return last().compareTo(element) > first().compareTo(element);
}

public Object[] getValues() {
Object[] result = new Object[2];
result[0] = first();
result[1] = last();
return result;
}

public static void main(String[] args) {
Range<Integer> range = new Range<Integer>(1, 4);
System.out.println(range.input(3));
System.out.println(range.input(5));
System.out.println(range.input(-2));
System.out.println(range.input(0));
System.out.println(range.input(1));
}
}

 

[Rhino]

Presumably, the OP wants his IntRange to behave like a Set<Integer>,
with contains, containsAll, iterator, etc.

If this is the case, extending AbstractSet (or possibly AbstractList) is
probably the way to go.

In all honesty, I can't remember what reasoning process I was going through
when I wrote this IntSet class. That was at least a year ago and I've long
since set the project aside, although I want to revive it at some point.

Everyone's comments are much appreciated but I'm not going to be able to act
on any improvements right now anyway; maybe in a couple of months if things
go well.... In the meantime, your remarks have helped me learn a bit more
about making warnings about Generics go away so thanks for that.

Rhino

 

[Torkel Franzen]

If my copy were in front of me, I would give chapter and verse. In
general, generics, and in particular, many of the examples that were new for
JLS 3 do not compile.

I would appreciate information about where these uncompilable
examples are to be found.

 

[Thomas Hawtin]

public boolean input(E element) {
return last().compareTo(element) > first().compareTo(element);
}

Very clever. But not actually correct.

I think it should go something like:

public boolean contains(E element) {
return
first().compareTo(element) <= 0 &&
element.compareTo(last() ) <= 0;
}

(Disclaimer: Neither tested nor compiled.)

Not that I think it is a brilliant idea. It appears that the original
intention was for a SortedSet of the range. That in general is not going
to work for a Comparable. String for instance would iterate over
successively long values.

Tom Hawtin

 

[Danno]

All my test cases passed just fine (Try it for yourself ):

Range<Integer> range = new Range<Integer>(1, 4);
System.out.println(range.input(3)); //true
System.out.println(range.input(5)); //false
System.out.println(range.input(-2)); //false
System.out.println(range.input(0)); //false
System.out.println(range.input(1)); //true

System.out.println("--------");

Range<Integer> range2 = new Range<Integer>(-5, 5);
System.out.println(range2.input(3)); //true
System.out.println(range2.input(5)); //true
System.out.println(range2.input(-2)); //true
System.out.println(range2.input(0)); //true
System.out.println(range2.input(1)); //true
System.out.println(range2.input(-5)); //true
System.out.println(range2.input(-8)); //false

I was assuming from the code that it was inclusive of the boundary.

 

[Thomas Hawtin]

All my test cases passed just fine (Try it for yourself ):

Just because all of your tests pass, it does not mean your code is
correct. Your tests are significantly inadequate.

Tom Hawtin

 

[Danno]

So test away some more at it. Crash it! It would only help out Rhino in
the end.
I was just helping someone here on usenet and not getting paid for
production quality code. Should I have put a disclaimer to satiate
the usenet code critics? Nah, they should test it for themselves.

Other than null handling, which this class doesn't have, I think it is
a pretty cool solution. Let me know of any fail case that you find.

Have fun
Danno

 

[Mike Schilling]

I would appreciate information about where these uncompilable
examples are to be found.

When I locate my copy (it appears to have been "borrowed"), I'll post them.

 

[Thomas Hawtin]

So test away some more at it. Crash it! It would only help out Rhino in
the end.

Cursory code review caught a problem (and not just that the code was
needlessly difficult to understand). I think you would gain more by
going back and thinking over the code. There are at least two things I'd
probably change in my own version.

I was just helping someone here on usenet and not getting paid for
production quality code. Should I have put a disclaimer to satiate
the usenet code critics? Nah, they should test it for themselves.

You put forward an obfuscated technique that is buggy (surprise!). Are
you not expecting anyone to pick up on that? No one should criticise
exceptionally poor code?

Other than null handling, which this class doesn't have, I think it is
a pretty cool solution. Let me know of any fail case that you find.

K3wl, certainly. Working, no. Often those things go together.

Tom Hawtin

 

[Danno]

Show me the buggy! hehe

Plus, it's not exceptionally poor code, I take umbrage at that, I think
it kicks ass for doing it in 10 minutes. If you don't find a bug in
that method, you owe me a tortilla.

 

[Thomas Hawtin]

Show me the buggy! hehe

Plus, it's not exceptionally poor code, I take umbrage at that, I think
it kicks ass for doing it in 10 minutes. If you don't find a bug in
that method, you owe me a tortilla.

You would save time if you wrote more straightforward code.

I expect you to find the bugs. It might persuade you to aim for simpler
code.

Tom Hawtin

 

[Danno]

Whatever
I think someone owes me a tortilla

 

[Luc The Perverse]

Whatever
I think someone owes me a tortilla

Huh why?

 

[Danno]

Because he said there is a bug and I say nay! NAY! I asked him to tell
me the bug, and I'd give him a tortilla. He is refusing, because I
think he is bluffing. For what it was worth in my few minutes of
jotting code late at night on c.l.j.p I thought that little tidbit was
weird albeit awesome!

So unless he gives me his expert test case, I am assuming he owes me a
tortilla.

 

[John C. Bollinger]

Very clever. But not actually correct.

You at least have to award him partial credit. I see one class of error
cases where the above method provides results inconsistent with Rhino's
between() method, but otherwise it does look like it works.

I think it should go something like:

public boolean contains(E element) {
return
first().compareTo(element) <= 0 &&
element.compareTo(last() ) <= 0;
}

(Disclaimer: Neither tested nor compiled.)

That one solves the problem I see with Danno's. Sorry, Danno, no
tortilla for you.

Not that I think it is a brilliant idea. It appears that the original
intention was for a SortedSet of the range. That in general is not going
to work for a Comparable. String for instance would iterate over
successively long values.

No, I think the intention was to hijack TreeSet's machinery to evaluate
properties and conditions of the range, such as the one you and Danno
are arguing over. The set itself is not intended to be an exhaustive
collection of the elements of the range, and might never contain more
than the two endpoints.

You're right, it's not a brilliant idea, but not for the reason you
mentioned. I think Rhino talked about this back when he first was
working on it; I didn't like it then, either.

 

[Danno]

Now if we are talking about taking it from the top and organizing a way
to do this correctly. I wholeheartedly agree. I wouldn't approach it
this way at all. All I did was take Rhino's code for better or worse
and converted it.

I sure like tortillas though.

 

[Oliver Wong]

Very clever. But not actually correct.

I think it should go something like:

public boolean contains(E element) {
return
first().compareTo(element) <= 0 &&
element.compareTo(last() ) <= 0;
}

(Disclaimer: Neither tested nor compiled.)

For what it's worth, I could not find an example where the two methods
would return different values given the same input, except if element is
null, in which case Thomas' method would throw an NPE, and Danno's method
would behave depending on how compareTo() is implemented.

This is assuming that the contract for compareTo() is properly obeyed,
and that first() and last() always return the same values, and that that
value is not null.

- Oliver

 

[Eric Sosman]

Oliver Wong wrote On 01/20/06 16:39,:

For what it's worth, I could not find an example where the two methods
would return different values given the same input, except if element is
null, in which case Thomas' method would throw an NPE, and Danno's method
would behave depending on how compareTo() is implemented.

This is assuming that the contract for compareTo() is properly obeyed,
and that first() and last() always return the same values, and that that
value is not null.

For what it's worth, two scenarios:

1: If the range is trivial (first() and last() compare
equal) and the element being tested is that same value,
Danno's method returns false while Oliver's returns true.

2: compareTo() returns a value whose sign is important
but whose magnitude is not. If last().compareTo(element)
returns 7 and first().compareTo(element) returns 3, Danno's
method returns true while Oliver's returns false.

 

[Thomas Hawtin]

For what it's worth, two scenarios:

1: If the range is trivial (first() and last() compare
equal) and the element being tested is that same value,
Danno's method returns false while Oliver's returns true.

2: compareTo() returns a value whose sign is important
but whose magnitude is not. If last().compareTo(element)
returns 7 and first().compareTo(element) returns 3, Danno's
method returns true while Oliver's returns false.

I think Danno owes Eric a tortilla on both counts.

Tom Hawtin

 

[Danno]

Damn! Oh well, you win some, you lose some.

If you are interested in some tortillas, email me with an address so I
can send them to you. I could also pitch in some chile from NM too.