Equality for values -- new analysis, same conclusion

[Brian Goetz]

> This mail continues a thread at valhalla-spec-experts.

Party foul!  There is a reason there are separate lists, and forking a 
thread from -experts to the -dev list -- especially one in such active 
discussion -- is not consistent with the charter, or spirit, of the -dev 
lists.  Please, let the experts do their work.  We do it in the open, 
but having concurrent discussions on both lists is value-destroying.  
When things appear to have settled, it might be more acceptable to weigh 
in like this on the -dev list, but still should be done with care.

> Firstly, I think the new direction of "values are objects" and using
> names/eclairs seems worth exploring and I don't have much to add
> (although I'm not looking forward to an alternate name or a default
> value for LocalDate).

I share your concern about the migration strategy.  Significant effort 
and resources were spent exploring whether in-place migration was 
practical, though, and it seems to be the consensus that the complexity 
costs of doing so outweight the (obviously significant) benefits.  So, 
while we didn't come up with the answer you (or I) wanted, I'll take 
that as a "thank you for trying really hard."

> I find myself mostly in agreement with Remi - in principle, the
> current == operator at the language level needs to die and be removed
> - it is a mistake of history.

Not surprising; you usually come down on the side of "X was a mistake, 
let's get rid of it" in these discussions.  But, not all users are as 
eager to ditch their intuition, even if the new intuition is in some 
sense "better".   Regardless, such didactic statements of "X is a 
mistake of history" are generally not helpful, because they prevent us 
from exploring the entire space, which often leads to creating 
constraints that leave us with bad choices elsewhere, so these things 
need to be considered holistically.  "I don't like how X was done in the 
past, this is our chance to fix it" is frequently a siren song.  (In 
fact, the reason we didn't see some of these simplifications sooner is 
that we assumed "in-place migration" to be a requirement, which in turn 
made it harder to see the costs.  Lesson learned, hopefully.)

> What I'd really like to see is some serious brain-power applied to the
> question of how to get from where we are today to a world where there
> is an operator for .equals() for all types (Objects and values).

I get why you want this, and I'm not hostile to the idea, but this is a 
separable (and by comparison, trivial) problem.  It is infinitely more 
important to define consistent and stable foundations for the basic 
underpinnings of the language and JVM, so we're focusing on that now.