----- Mail original -----
> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>, "John Rose" <john.r.r...@oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net>
> Envoyé: Jeudi 21 Février 2019 02:48:09
> Objet: Re: acmp again !
>>
>> It doesn't match my experience, currently people have no expectation of what
>> ==
>> means on a value type, if you explain that a value type has no identity, that
>> == doesn't work on a value type, most people are ok with that.
>
> I think this is fantasy.
yes, and == doing a component wise equals is hell and there are no good place
in between ... again pick your poison.
>
> Value types are OBJECTS. People think they know what == means on an
> Object, and for most users, the word "identity" does not come to mind.
devs already know what an identity is because
- the way boxing/unboxing is defined in 5
- the way value based class are defined in 8 (classes defined as not
identity-sensitive).
so they may not know the term "identity" but they know the concept under the
term "boxing".
> Further, we've told people that "values have only state, no identity --
> if two values have the same state, they are the same." For such values
> not to be == will be astonishing.
>
> Consider:
>
> value class UnsignedInt {
> public static UnsignedInt ZERO = ...
>
> private int i;
>
> public static add(UnsignedInt a, UnsignedInt b) { ... }
> }
>
> UnsignedInt x = ...
> if (x != UnsignedInt.ZERO) { ... }
>
> People will never, ever, ever get used to the idea that test is always
> false.
This example does not compile, you can not do a == or a != on a value type, you
have to use equals() like you have to do a equals() on String otherwise you
have unpredictable result.
Compare your example with
Integer x = ...
if (x != Integer.ZERO) { ... }
most of my undergraduate students (you still have one or two black sheeps) will
tell you that you should use equals() here and not ==.
The mental model for our users is that seeing a value type as an Object or an
interface is a kind of boxing but it's better because
- the compiler doesn't let you write code that have unpredictable result (that
why == is disable on value types)
- if you compare boxed value types as Object using ==, it will always return
false, again it's better than sometimes returning true and sometimes returning
false like when you box Integers.
BTW, using a static field in your example is a premature optimization, you can
use a static method if you want a name given that values are not heap allocated.
> Its a fantasy to think otherwise. And the WHOLE POINT of
> L-World is to allow people to not sweat the small details between values
> and refs. This is asking them to be acutely aware all the time.
No, the whole point of L-World is to see value types as ref types but you can
see the artifice for all identity-sensitive operations. Synchronized throwing
an ISE is in the same category.
Trying to hide that under the rug and pretend it's just small details is wrong
to me.
I prefer a model that is reliable while surprising at first than a model that
allows unbounded computations.
Rémi
