Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 3.0
-
Component/s: None
-
Labels:None
-
Number of attachments :
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
Issue Links
- is depended upon by
-
GROOVY-2503
MOP 2.0 design inflluencing issues
-
- is related to
-
GROOVY-1765
The equality and relational operators can not be overridden by a Category method
-
-
GROOVY-2576
Add "implies" operator for boolean expressions
-
- relates to
-
GROOVY-1889
Make all operators interceptable
-
| 1. | GString vs String equality in collections | |
Open
|
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 |
Activity
| Field | Original Value | New Value |
|---|---|---|
| Link | This issue is related to GROOVY-1765 [ GROOVY-1765 ] |
| Link | This issue depends upon GROOVY-2576 [ GROOVY-2576 ] |
| Link | This issue is related to GROOVY-2576 [ GROOVY-2576 ] |
| Link | This issue depends upon GROOVY-2576 [ GROOVY-2576 ] |
| Link | This issue relates to GROOVY-1889 [ GROOVY-1889 ] |
| Assignee | Jochen Theodorou [ blackdrag ] |
| Link | This issue is depended upon by GROOVY-2503 [ GROOVY-2503 ] |
What ever implementation (one or multiple methods) will be selected, comparison operator methods should be allowed to return arbitrary types, not only boolean (and certainly not only integer) results. Otherwise utilization in DSLs is too much restricted (as is the case with Groovy 1.x).
See discussions at http://www.nabble.com/Overloading-comparison-operators-td18504388.html and http://www.nabble.com/operator-overloading-td12984525.html.