Proposal: Sameness operators

[Stephen Colebourne]

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
>>
>
>
>