Equality for values -- new analysis, same conclusion

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Lundi 12 Août 2019 21:47:00
> Objet: Re: Equality for values -- new analysis, same conclusion

>> and here we disagree,
>> first, you don't have to extend ==, you can let it die.
> 
> I agree that is a possibility (and I've been quite clear about this).
> Where I don't agree is that this is the _only_ sane possibility, nor do
> I agree that this is somehow intrinsically desirable.  You've flat-out
> assumed that it is, and gone running from there, which is a totally fair
> opinion, but rates a zero on the persuasion scale....

not zero, i was able to convince Stephen it seems :)

> 
> So, if you want to make this case, start over, and convince people that
> Object== is the root problem here.

Object== is not the root of the problem, Object== becomes a problem when we have decided lword, when at the end, every types is a subtype of Object, because this is what lworld is.

== has been created with ad hoc polymorphism in mind (overload polymorphism is a better term BTW), let say your are in Java 1.0 time, you have a strong rift between objects and primitive types, and no super type in between them, the way be able to write polymorphic code is to use overloading, so you have println(Object)/println(int)/println(double) etc. But it's not enough, so in 1.1 you introduce the wrapper types, Integer, Double etc, because you can not write reflection code without being able to see a primitive value as an Object. Here, we are doing the opposite, since we have decided to use lworld, Object is the root of every things, indirect types obviously, inline types too. We also know that in the future, we don't want to stay in a 3 kinds of types world. So we have to retrofit primitive types to see them as inline types. By doing this, we are also saying that every types has now Object has its root type. In this brave new world, val== makes little sense, because it's introducing a new overload in a world where you have subtyping polymorphism so you don't need overload polymorphism anymore. For an indirect type, the way to test structural equality is to use equals(), if every types is a subtypes of Object, the logical move for me is to say, use equals() everywhere and to stop using ==.

So having a useful val== or a useful Object== goes in the wrong direction, we should demote == and look to the future*.

Rémi


* and it's very intellectually satisfactory to have a solution which means that our users will have less thing to learn instead of more, i'm thrill that there will be a time where my students will be able to use .equals on a primitive types.