Proposal: Sameness operators

[Derek Foster]

-----Original Message-----
>From: Tom Hawtin <Thomas.Hawtin at Sun.COM>
>Sent: Mar 31, 2009 7:09 AM
>To: Derek Foster <vapor1 at teleport.com>
>Cc: coin-dev at openjdk.java.net
>Subject: Re: Proposal: Sameness operators
>
>Derek Foster wrote:
>> a $$ b    "same as":              a==null ? b==null : a.equals(b), or a == b for primitive types.
>
>$ and $$ are valid identifier in (existing) Java. Not a lot of people 
>know that. http://jroller.com/tackline/entry/things_i_didn_t_know

I, however, do know it. In fact, I mentioned it in the "Breaking Changes" section of my proposal. However, use of generated code is rare in general, and fixing a code generator to comply with a new language version only has to be done once. I considered it a lesser risk than introducing syntax that might break non-generated programs, which are very common indeed.

I am open to other operators being used instead of the ones I suggested. I considered >#, <#, ##, and !#, for instance, but I thought that too many people might want to use # for closure-related things. Mostly, I wanted readability and understandability. The idea is you can just replace an = (which means "object identity" aka "equals") with a $ (which means "object equality" aka "sameness") and the related operators tend to mean what you would expect them to.

>> a !$ b    "not same as":          a==null ? b!=null : !a.equals(b), or a != b for primitive types.
>> a >$ b    "greater than or same": a.compareTo(b) >= 0, or a >= b for primitive types.
>> a <$ b    "less than or same":    a.compareTo(b) <= 0, or a <= b for primitive types.
>
>That's going to be jolly confusing for BigDecimal users (but I guess 
>that is not a state change).

Personally, I find

if (a >$ b) { do stuff }
if (a $$ b) { do stuff }

a lot less confusing than:

if (a.compareTo(b) >= 0) { do stuff }
if (a == null ? b == null : a.equals(b)) { do stuff }

so I would hope that these would eventually reduce the confusion, not add to it. Really, the confusion is already there in how or if classes like BigDecimal implement interfaces like Comparable. (Which maybe was your point.)

Derek