Value equality

[forax at univ-mlv.fr]

----- Mail original -----

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Valhalla Expert Group Observers"
> <valhalla-spec-observers at openjdk.java.net>, "Brian Goetz"
> <Brian.Goetz at oracle.com>
> Envoyé: Jeudi 19 Mai 2016 01:01:37
> Objet: Re: Value equality

> On May 18, 2016, at 3:58 PM, John Rose < john.r.rose at oracle.com > wrote:

> Yes but if CE is a subset of OE then their union is just OE. (Viewing
> relations as sets of pairs.) In your example that is the case. Any .equals
> method must extend CE or it breaks the .equals contract.

> – John

It doesn't seem practical to me to add this constraint: 
- there is no way to enforce that constrain but to run the code. 
- it will make the retrofitting of a class to a value class hazardous. 

Rémi 

> > On May 18, 2016, at 3:52 PM, Remi Forax < forax at univ-mlv.fr > wrote:
> 

> > Even without talking about optimizations,
> 

> > LIFE for a value type is not correct because CE may not be included in EQ.
> 

> > value class Foo {
> 

> > int value;
> 

> > public boolean equals(Foo foo) {
> 

> > return value & 0xFF == foo.value & 0xFF;
> 

> > }
> 

> > }
> 

> > here, if CE do a bitwise comparaison, the semantics of LIFE is not the
> > semantics of EQ.
> 

> > Rémi
>