Skip to end of metadata
Go to start of metadata

Every book on C, C++, or Java style warns programmers about the danger of confusing "=" (assignment) with "==" (equality). Python made assignment a statement, rather than an operator, in part to prevent mistakes of the form:

while (something = someCall())  // should be "=="
{
}

Right now, Groovy makes matters worse by:

  • changing the meaning of "==" (to mean data equality intsead of object identity), and
  • introducing "===" for object identity.

Given that "===" is harder to distinguish from "==" than "==" is from "=", we should introduce a new keyword is for object identity, and remove "===" from the language. (In fact, we should probably go back to using "==" for identity, so as not to confuse programmers who are moving back and forth between Java and Groovy...)

  • No labels

2 Comments

  1. But.. ee.. I don't understand, what this page is? It is placed under "specification" ("contains the current version of the specification (things we've agreed on)"), but it contains phrases "we should probably" or "right now".

    My opinion is "===" is fine. Identity test is rarely used, but "is" as idendifier – often, as name of variable for InputStream, for example.

  2. FWIW the reason we use == for .equals() in Groovy is because

    • in Java we often end up with complex logic to handle nulls properly e.g. instead of this Java

    we can in Groovy just do

    which handles nulls for you

    • in Java primitive types use == whereas objects use .equals. We found that often people would write this

    which if == means identity would often fail - which is why we changed == to mean equals for any type of object in Groovy