<div dir="ltr">Thanks, Remi. Very interesting, more than answers my question!<div><br></div><div>John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 9, 2024 at 7:09 AM Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><div><br></div><hr id="m_-2064502490476395393zwchr"><div><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"John Bossons" <<a href="mailto:jbossons@gmail.com" target="_blank">jbossons@gmail.com</a>><br><b>To: </b>"valhalla-dev" <<a href="mailto:valhalla-dev@openjdk.org" target="_blank">valhalla-dev@openjdk.org</a>><br><b>Sent: </b>Monday, April 8, 2024 4:30:44 AM<br><b>Subject: </b>Implementation of == and Object::equals</blockquote><div><br></div><div>Hi John,<br></div><div>adding to what Roger said,<br></div><div><br></div><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><br></blockquote></div><div><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr">I'm not sure that this is the right place to raise this, but don't know where else to do so.<br><div>For identity types, == is simply a test of reference equality and so is a useful first test in an overriding type-specific equals method. </div></div></blockquote><div><br></div><div>No, it's a bad idea performance-wise.<br></div><div>see <a href="https://youtu.be/kuzjX_efuDs?list=PLX8CzqL3ArzV4BpOzLanxd4bZr46x5e87" target="_blank">https://youtu.be/kuzjX_efuDs?list=PLX8CzqL3ArzV4BpOzLanxd4bZr46x5e87</a><br></div><div><br></div><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><br><div>For value types, the relationship is more subtle, since == is a test of value equality, not reference equality. I suggest it be implemented as an operator causing Object::equals to be invoked, so that if Object::equals is overloaded (e.g. to first test equality of hash codes or otherwise modify the default equals test), the overloaded method is automatically invoked when == is used.</div><br><div>This would mean that Object::equals implements the == operator, rather than the reverse, so that a specification that a == b always means a.equals(b), whether implemented by the default test or by an overriding type-specific method (that e.g. tests for equality of identity object field values). I believe this would make value types (especially value trees) easier to use.</div></div></blockquote><div><br></div><div>Two things, (1) the semantics of equals() on a class (value or identity) is stronger than the semantics of == on a value class, (2) what you propose introduce a circularity between == and equals, so if equals itslef uses ==, it's an infinite loop.<br></div><div><br></div><div>Imagine you have a value class defined like this:<br></div><div>  value class MyValueClass {<br></div><div>    String s;<br></div><div><br></div><div>    public boolean equals(Object o) {<br></div><div>      return o instanceof MyValueClass other && s.equals(other.s);<br></div><div>    }<br></div><div>  }<br></div><div><br></div><div>1) calling == on an instance of MyValueClass should check if s == other.s, not calling s.equals(other.s) on the field "field" so the semantics of == is different from the semantics of equals.</div><div><br></div><div>2) if we write equals like that and == calls equals()<br></div><div>  <div>   public boolean equals(Object o) {</div><div>      return this == o && o instanceof MyValueClass v && field.equals(v.field);</div><div>    }</div><br></div><div>we have an infinite loop.<br></div><div><br></div><div>That's why == on value type is defined as doing == on each field and not as calling equals on each field.<br></div><div><br></div><div>That's said, in the future, for some value types, we may let users to be able to override == and identity hashCode so anyone can write it's own primitive type, but it will not be the default behavior and we are not there yet.<br></div><div><br></div><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><br><div>John</div></div></blockquote><div><br></div><div>regards,<br></div><div>Rémi<br></div><div><br></div><blockquote style="border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px;padding-left:5px;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><div dir="ltr"><div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Phone:  (416) 450-3584 (cell)</div></div></div></div><br></blockquote></div></div></div></blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Phone:  (416) 450-3584 (cell)</div></div>