Draft proposal: allow the use of relational operators on Comparable classes

[Howard Lovatt]

Dots are also a bad solution because you can get confusing expressions:

5.<.4

Is this:

(5.) < (.4)

or

Integer.valueof( 5 ).compareTo( Integer.valueof( 4 ) ) < 0

Therefore I withdraw the suggestion of using dots. Sorry!

In hindsight I think that you can only improve comparisons by having a
source statement, see proposal for source and encoding, that allows
you to make bigger changes in the future. The source statement goes at
the start of the file and tells the compiler which version of Java the
file is in, no source statement means Java 6. So for example in Java 7
we we put, source Java7 at the start of the file. If source were added
to Java 7 then in a future version, say 8, we could:

1. Fix the operation of primitive comparisons, i.e. make them
consistent with Double.compareTo and Float.compareTo

2. For Float op Float and Double op Double un-box the values and
perform primitive conversions (so that type is automatically promoted)

3. Then make the comparison operations call compareTo for other types
if Comparable is implemented

4. Use == to call equals if Comparable is not implemented (similarly !=)

5. Introduce === which means compare addresses

Can't see that we can do much in this area without source adding first.

Cheers,

Howard.

2009/3/18 Olivier Chorier <lapsus63 at gmail.com>:
> I think dots are not a good solution because IDE are used to propose
> auto-completion with it
>
> 2009/3/18 Howard Lovatt <howard.lovatt at iee.org>
>>
>> You could use new operators:
>>
>> .<.
>> .<=.
>> .>.
>> .>=.
>> .==.
>>
>> The dots are meant to remind everyone that a method, comparable, is
>> called.
>>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>