Automatic generation of the "compareTo" method
stlecho
for instance by adding the @compareTo annotation.
Reinier Zwitserloot
--Reinier Zwitserloot
Does Lombok allow to automatically generate the "compareTo" method,
for instance by adding the @compareTo annotation.
--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/
To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to
project-lombo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/project-lombok?hl=en
Roel Spilker
Can you show us a before and after image to clarify what you mean? For
example:
Before @Foo
class X {
// code
// code
// code
// code
// code
// code
}
After @Foo
@Foo class X {
// code
}
Where both the before and after image would execute the same.
Roel
Michael Lorton
Sent from my iPhone
Tuure Laurinolli
> As a default, you could compare every Comparable member -- like the
> default equals.
Yes, but in which order, and do you think it would really be OK to
exclude non-Comparable members (that still affect equals())?
v6ak
declaration. I also think that non-excluded non-comparable members
should cause an error.
On Mar 1, 7:44 pm, Tuure Laurinolli <tuure.laurino...@indagon.com>
wrote:
Michael Lorton
M.
Daniel Yokomizo
In the simplest scenario It could be something like this:
@CompareTo
class Foo implements Comparable<Foo>{
private String s;
private int i;
}
//becomes
class Foo implements Comparable<Foo>{
private String s;
private int i;
public int compareTo(Foo that) {
int order = (this.s == that.s) ? 0 : (this.s == null) ? -1 :
(that.s == null) ? +1 : this.s.compareTo(that.s);
order = (order != 0) ? order : (this.i == that.i) ? 0 :
(this.i < that.i) ? -1 : +1;
return order;
}
}
Also would be nice if @Data implied in @CompareTo iff it's Comparable.
OTOH I see a few issues with this approach:
1. Some fields aren't comparable. Particularly collections and arrays.
2. null handling: null is smaller or larger.
3. Some fields shouldn't matter for comparison, but using different
fields for equals and compareTo is (probably) always a bug, so we need
to keep these in sync.
4. Sometimes the default comparison is not what we want.
A few solutions:
1. Introduce an utility class with a bunch of overloaded compare(X,
X), compare(X, X, Comparator<X>), deepCompare(X, X) and deepCompare(X,
X, Comparator<Object>) (i.e. arbitrary nesting is handled by
recursion, the comparator is used when dealing with elements).
2 & 4. An additional @CompareWith(value = Class<Comparator>,
nullOrder = NullOrder /* enum with NULL_IS_LESSER and
NULL_IS_GREATER*/) can deal with these issues, but it would require
some additional design (e.g. do we cache the Comparator instances
using a ThreadLocal?).
3. This points to making this feature a part of @EqualsAndHashCode
and @Data when the underlying class is Comparable.
Best regards,
Daniel Yokomizo
P.S.: This discussion makes clearer to me that Lombok features can be
divided in two broad categories:
1. Language extensions or macros (e.g. Cleanup, Synchronized, SneakyThrows).
2. Creating stuff derived from the internal structure of a class
(e.g. Data, EqualsAndHashCode, ToString). This category is very
similar to how "deriving" works in Haskell and Lombok can be seen as
the Java equivalent of DrIFT
(http://repetae.net/computer/haskell/DrIFT/).
Condor
Reinier Zwitserloot
--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.