----- Mail original -----
> De: "Brian Goetz" <[email protected]>
> À: "Remi Forax" <[email protected]>
> Cc: "valhalla-spec-experts" <[email protected]>
> 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.

Reply via email to