acmp again !

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "John Rose" <john.r.rose at oracle.com>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at 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