'Equals' in any-typed code: VERY BIG PROPOSAL

[Vitaly Davidovich]

Why do we need a new special operator? What's wrong with using equals ()
and having the specializer rewrite that for primitives? For other types
(refs and custom value types), it should just delegate to the real equals.

Sent from my phone
On Jan 7, 2015 6:15 AM, "Thomas W" <twhitmore.nz at gmail.com> wrote:

> Hi John, Maurizio, people
>
> Thanks for your comments on equals/ null.
>
> > You are right that the "==" operator has some very sharp edges when we
> try to unify references and primitives.  (So does "+".)
> > On references, it is often used invalidly, and has valid uses for null
> checks, short-cutting calls to x.equals(y), and work with interned types
> (like enums).
>
> Equality checking across values/ reftypes really would benefit from a clean
> syntax.
>
> I feel it is a hack to be writing a null- check, and we should avoid
> encouraging null to be written in 'any' typed code!
>
> Now, am I going to ask you to marry me?
>
> No, but I am going to propose an 'eq' operator. Into the Java language. As
> such:
>
>     if (node.getKey() eq key) {
>     if (name eq "") {
>     if (product.getColor() eq color) {
>
> As well as solving equals for 'any', such an operator would address one of
> the biggest pain points for millions of application developers working in
> Java.
>
> Millions would cheer, and the world would thank us.
>
> I would also consider a 'neq' not-equal operator. These one or two
> operators are of such benefit & as by far the most important, can easily be
> justified to stand on their own.
>
>     if (value neq other.value) {
>
> Clean scope, no need to bring in other operators/ comparisons, just a
> compact & benefical feature..
>
> Could this be the right time? We have a real requirement, an opportunity
> for long-term benefit, and a release where bold changes can be accepted.
>
> Regards
> Thomas Whitmore
>