Proposal: Sameness operators

[Reinier Zwitserloot]

It's certainly the best backwards compatible alternative that I have  
ever seen, but they are still FAR from ideal.

Take your average programmer who is just reading some code. He first  
sees:

a == b

He rightly assumes this is some sort of equality check, though he  
would probably be surprised to learn that in java, it's object pointer  
identity, not object equality, if a and b are objects. Still, that's  
one sort of (mostly useless) equality, and it is the same as C's  
meaning for this operation, which is not an unimportant benefit,  
because many things in java that look indistinguishable from C code do  
roughly the same thing.


Then he sees:

a (==) b

a few lines down, and now he's just confused and will need to hit the  
books to figure any of this out. I'll grant you that the readability  
of the current situation is not very good either, and I will certainly  
grant that the practical nature of the == operator is very bad indeed  
(In fact, when this comes up in discussion, I always suggest just  
dropping support for object identity altogether in the language, and  
moving that to System.identicalPointers(a, b) or some such. Who needs  
to know about this stuff? Nobody. It's like copying arrays quickly.  
Yes, java should be capable of doing it, but not even close to useful  
enough to warrant an operator!)

Crazy idea: We can get a little closer to ideal by creating a class in  
java lang with useful static methods which you can then import, like:

public static void is(Object x, Object y) {
     if ( x == null ) return y == null;
     return x.equals(y);
}

public static void is(Object x, int y) {
    // Yes, you'd need a few gazillion is methods to cover all the  
primitives on either side, but 1 static import will grab all of them
}

... loads more is methods


Then same with lt, gt, le, ge.

Then you could write:

if ( is(a, b) ) {
   //doStuff
}

Which is a small improvement.

Add an ability to specify 'as infix' in static imports, and you have  
pretty much what we all want without backwards compatibility issues:

import static java.lang.Equality.is infix;

if ( a is b ) {
   //do something
}

I'd consider that a large improvement.


In my perfect world:

':=' is assignment, assignment to a boolean is no longer an expression  
but just a statement to avoid bugs, '=' is equality, and '==' is a  
deprecated syntax for System.identicalPointer, or just '=' for  
primitives/unboxables.

That would no longer be even remotely compatible with java as is,  
though.

  --Reinier Zwitserloot



On Apr 2, 2009, at 14:24, Stephen Colebourne wrote:

> The best alternative operator symbols I've come up with yet are  
> bracketed ones:
>
> a (==) b
> a (<) b
>
> I don't think that the symbols are ideal, but they do look reasonably
> readable, and its way better than .equals().
>
> Do I expect anything to happen here? No. There is a long history of
> "operator overloading"  being frowned on in the Java language. The net
> result is more of an argument to use Groovy, Scala, Fan etc.
>
> Stephen
>
>
> 2009/4/2 Reinier Zwitserloot <reinier at zwitserloot.com>:
>> 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
>>>
>>
>>
>>
>