Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
Description
as not everything we want to let <,==,>,<=,=>,<==> operate on is a total order, it would be nice to have one of these defined only. Also the current solution with Comparable seems to lead to many problems, because Comparable itself is thought to be used with an exact counter part, but we might want to let it work on other classes as well. for this we should go away from Comparable. I would suggest we write a single method with a bitfield containing flags for <,> and ==. Then the user can throw an exception if a flagged operation is not available, also he can implement only < (100) or > (010) or == (001) or <= (101) or =>(011) or <=> (111). the way to keep backwards compatibility with this would be to add a compareTo method that uses the bits 111.. Well needs more discussion
Attachments
Issue Links
- is depended upon by
-
GROOVY-2503 MOP 2.0 design inflluencing issues
-
- Open
-
- is related to
-
GROOVY-7608 Comparison of decimal subclasses of Number with == fails
-
- Closed
-
-
GROOVY-1765 The equality and relational operators can not be overridden by a Category method
-
- Open
-
-
GROOVY-2576 Add "implies" operator for boolean expressions
-
- Closed
-
- relates to
-
-
- Open
-
1.
|
GString vs String equality in collections |
|
Closed | Unassigned |
2.
|
== operator uses compareTo instead of equals to calculate its result for Comparable classes |
|
Open | Unassigned |
3.
|
== uses compareTo if groovy class is a comparable |
|
Open | Unassigned |
4.
|
Non commutative behavior of == operator with Gstring and Integer |
|
Open | Unassigned |
5.
|
The compareTo method is not commutative for String and GString when used from Java |
|
Open | Unassigned |