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

[Martijn Verburg]

Hi Thomas,

If you're keen to explore this space I'd recommend taking a look at what it
would take to implement these proposed operators and explore their
interaction with existing ==/!= and equals() mechanics and how it would all
work when dealing with primitives, boxed objects, arrays, nulls and general
objects with/without a .equals() defined, not to mention the proposed
'value type' construct....

I know it's tempting to look at these issues from the "Java the language"
perspective (with some pseudo syntax), I've fallen for this trap in the
past as well! It's infinitely better to propose these ideas from the view
of the JVM and it's internal mechanics, which I appreciate takes a lot of
time and effort :-).


Cheers,
Martijn

On 7 January 2015 at 11:14, 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
>