<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">You are right that developers will
frequently do dumb things in search of concision or perceived
performance advantage, but I don't think that's a compelling
argument for "so then let's create yet another spelling for
equality". <br>
<br>
But, underlying the concern you raise is that developers are
frequently put in the position of worrying whether to use `==` or
`.equals()`. One thing Valhalla does do to make this better, but
in a perhaps surprising way, is that it makes it practical to just
always use equals(). <br>
<br>
Consider implementing the equals() method of a class like:<br>
<br>
class C { <br>
int i;<br>
String s;<br>
<br>
public boolean equals(Object other) { <br>
return other instanceof C c<br>
&& i == c.i <br>
&& s.equals(c.s);<br>
}<br>
}<br>
<br>
Until Valhalla, there is no equals method to call on `int`, so
using `==` for int and `.equals()` for String is the only
semantically correct move -- and this asymmetry is irritating.
But with Valhalla, you can write:<br>
<br>
</font><font size="4" face="monospace"> return other
instanceof C c<br>
&& i.equals(c.i)<br>
&& s.equals(c.s);<br>
<br>
without fear of "oh, but that means I am going to box, which is
dumb". The int::equals call will unroll to a simple bitwise field
comparison, and we can now happily write our equals methods
uniformly to use `.equals()` 99% of the time, and only when
identity really matters do we fall back to `==`. <br>
<br>
Now, this doesn't do anything for "but I want to type this with as
few characters as possible", but not having to think about either
"which comparison do I have to use" (most of the time) and the
perceived cost of boxing (most of the time) is surprisingly
freeing. <br>
<br>
If in ten years we decide we still want `===` as a shorthand, it
becomes purely a syntactic decision, separated from all the
accidental considerations. Ask me again then!<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 3/12/2024 3:14 PM, Jonathan F wrote:<br>
</div>
<blockquote type="cite" cite="mid:CABR7qmdMFFqj-bDpHc3JKUTL7Wyj-eYJODJmu_gwrJX_EmkUxg@mail.gmail.com">
<style>body{font-family:Helvetica,Arial;font-size:13px}</style>
<div style="font-family:Helvetica,Arial;font-size:13px">
<div style="margin:0px">I was going to bring up equals() and
operator overloading like Stephen, but for a completely
different reason, so here goes… Brian’s said in the past that
an operator notation for equals() is probably not a priority
right now. But I think there’s strong reasons for adding it
_at the same time_ as Valhalla, and IMHO there’s also a good
notation available:</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">- With Valhalla developers will
gleefully start using == with their new value classes (I know
I will). Because (a) they’ll be regarded as ‘user-defined
primitives’, (b) x.equals(y) is so awkward, let alone
!x.equals(y), (c) == may be seen as potentially faster than
equals().</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">- The catch, as we know, is that ==
_usually_ does what we want for value classes (which is
basically equals()), but usually doesn’t when there are
identity fields. So each class has to document == somewhere as
if it’s a method without a predictable meaning.</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">Case in point: if Color were a value
class, many would assume they can use == for equality, but
that wouldn’t work if the RGBA are stored in an array. IMHO
the solution has to be to wean developers off == and onto a
new equals() operator, not to tell them to take more care
reading the class’s Javadoc. It’s too risky.</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">But no operator seems ideal since =
isn’t available: I think that’s why we are where we are.
However… I’d suggest === and (say) =/= would work well if IDEs
are encouraged to _display_ them as the equivalence symbols ≡
and ≢ (U+2261/2262), which IntelliJ IDEA already does. They’re
attractive and make mathematical sense: see various uses in <a href="https://en.wikipedia.org/wiki/Triple_bar" moz-do-not-send="true" class="moz-txt-link-freetext">https://en.wikipedia.org/wiki/Triple_bar</a>
. Possibly even allow ≡ in source code too - Java is the
original Unicode-based language, after all…</div>
<div style="margin:0px"><span class="Apple-tab-span" style="white-space:pre"> </span></div>
<div style="margin:0px">If this seems just too novel, it could
be pointed out that C’s == never made sense as a math notation
and != even less. I see x ≡ y (typed as x === y) as a clear
upgrade from x == y, let alone from x.equals(y). It could also
open the door for other Unicode operators in future.</div>
<div style="margin:0px"><br>
</div>
<div style="margin:0px">Jonathan</div>
</div>
<div>
<div>Jonathan Finn</div>
<div><br>
</div>
</div>
<br>
<p class="airmail_on">On 11 March 2024 at 22:38:34, Stephen
Colebourne (<a href="mailto:scolebourne@joda.org" moz-do-not-send="true" class="moz-txt-link-freetext">scolebourne@joda.org</a>)
wrote:</p>
<blockquote type="cite" class="clean_bq"><span>
<div>
<div>Is there a plan for operator overloading in Valhalla?
As far as I'm
<br>
aware there isn't a public plan, and I'm not asking for
one in
<br>
response to this email. Instead I'm asking if a plan is
likely in the
<br>
future and how it fits into Valhalla timescales.
<br>
<br>
I raise this because of the issue with the meaning of ==
on
<br>
Float/Double value types. Bitwise comparison is absolutely
fine and
<br>
correct for a JVM-level sameness test. But it is *never*
what a
<br>
developer wants when writing a business application, hence
discussion
<br>
of alternative approaches such as normalization.
<br>
<br>
If == was spelled differently (such as an `Objects.same(a,
b)` method)
<br>
then the recent debate would be irrelevant. But the
current proposal
<br>
is:
<br>
- the only equals operator is spelled ==
<br>
- it works 100% correctly for numeric value types
including
<br>
Float/Double except for the NaN edge cases
<br>
Given these two facts, == *will* be widely used as the
equals operator
<br>
irrespective of the authors' wishes. Just as it is for
Enum and Class
<br>
objects. This will inevitably lead to bug reports where ==
on two
<br>
different NaN returns false.
<br>
<br>
As such, I raise the question as to whether there is any
kind of plan
<br>
or priority to provide an operator mapping to
Object.equal() for all
<br>
types in Java, not just value types. If you can say that
there is such
<br>
a plan, then the == on Float/Double issue mostly goes
away.
<br>
<br>
Stephen
<br>
</div>
</div>
</span></blockquote>
</blockquote>
<br>
</body>
</html>