valhalla-dev Digest, Vol 7, Issue 24

[Thomas W]

Hi Simon, Vitaly, people,

Lots of people have been talking about adapting Collections for 'any' type.
Going forwards, I do not believe we should be writing code that explicitly
uses/ or checks for nulls (though we may be backwards-compatible for a
while) any more than we should be writing or calling a Duck.woof() method.

To answering a few questions:

> a) What are the actual semantics?

For ref-types:
    x eq y  -->   (x != null && x.equals(y))
For value-types:
    x eq y  -->   (x == y)

> b) How is this different to the approaches already outlines earlier?

It provides a basic logical building-block (equality check) at the language
level, in a way that works both for primitives/valuetypes and for nullable
references. It addresses a very big long-standing pain point in Java
application development. It avoids writing/ or encouraging "Duck.woof()"
style-hacks -- null checks -- into a domain that does not uniformly support
them.

> Why do we need a new special operator? What's wrong with using equals () and
having the specializer rewrite that for primitives?
> 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.

To have a proper logical equals in one operator, which is independent of
implementation & null-safe for reftypes.

What's wrong is writing null-checks & nulls, in a domain where nulls may
not exist.
We are not dealing with Dog, we are dealing with Animal and there should be
no 'woof()' method.

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

What's wrong with an operator that logically has exactly the right meaning,
without exposing details that don't exist in the domain?
It also provides a vast benefit for application programmers, as this kind
of requirement is ridiculously common in hundreds of millions of lines of
application code.


Regards,
Thomas Whitmore