Proposal: Sameness operators

[Reinier Zwitserloot]

Why can't we use compareTo and equals?

.<. syntax had severe problems that disqualified them - see the  
archive of this mailing list.

'is' has slightly more precedence than 'eq' and the set 'eq', 'ne',  
'lt', and 'le' need 'gt' and 'ge' as well, which makes them rather  
unwieldy. You can reduce a thing or two by going with just 'eq', 'lt'  
and 'gt', filling the holes with && and ! as usual (not equal becomes ! 
(a eq b)), or even a !eq b, but this is all devolving into way too  
much slap-dash language design unless those become global, non-context  
sensitive keywords. I'm okay with that, but Joe Darcy definitely  
isn't, so that's right out, at least for now.

More symbols is similarly unwieldy; there are no appropriate symbols  
for these operations available. It would be an even greater mistake to  
come up with some non-standard and unwieldly syntax for them, such as  
$=. That way lies perl cartoon-swearing craziness and nobody wants  
that. Wholesale operator overloading would be far preferable to that  
situation. ":=" for some sort of inference typing would make some  
sense and is still free, but that's about where it ends.


The cleanest solution to me remains a cleaning of the slate, so to  
speak, and an explicit demarkation in your source file that you're on  
'new java', such as with "source 1.8". With that at the top, "a == b"  
is compiled the same way as old java's "a == null ? b == null :  
a.equals(b)" for non-boxable objects (for unboxables and primitives,  
Unbox everything you can, then do a numeric comparison, or if it's  
primitive v. object, error), "a < b" and its ilk translate  
to .compareTo for non-unboxable Comparables, lead to unboxing for  
unboxables, no change for primitives, and error otherwise. Past  
mistakes are rectified, blahblahblah. We've been over this before, I'm  
sure most coin-dev readers have a good idea about how such a thing  
would work and the decade+ timerift it would cause between code bases  
that (stubbornly?) stay with non-new java.



  --Reinier Zwitserloot
Like it? Tip it!
http://tipit.to



On Apr 1, 2009, at 20:26, Tom Hawtin wrote:

> Christian Fischer wrote:
>> These $-operators doesn't seem intuitive to me, but replacing equal- 
>> calls
>> sounds interesting.
>>
>> Maybe a better solution would be something like this:
>> if (a eq b) // equals
>> if (a ne b) // not equal
>> if (a lt b) // lesser than
>> if (a le b) // lesser or equal
>
> Along with other concerns, four new keywords?! Theoretically they  
> could
> be context sensitive, but then we are boxing in the grammar.
>
> If something like this were to be done (and let's face it, operator
> overloading ain't gonna happen in JDK7), then I think there needs to  
> be
> to changes in fundamental direction of the proposal.
>
>  * We need new symbols. .<. and the like were proposed in another
> similar proposal. So long as the symbol is a sequence of characters
> which is not valid in an existing Java program (outside of comments  
> and
> literal strings).
>
>  * I think it's clear that we can't use Comparable.compareTo and
> Object.equals. It requires a new method for each operator.
>
> Tom
>