Finding the spirit of L-World

[Brian Goetz]

Forgot to comment on this:

> And that means that equals() has become the substitutability test that 
> people WANT. 

I agree with this completely.  But, where I think I disagree (and this 
is often the place where you and I reach for different tools) is that I 
don't want to use the language spec to discourage this.  I want to have 
the language spec assign it a clear, precise, sound, principled meaning, 
and then we can use lore, advice, static analysis, style guides, code 
samples, and electric shocks to encourage people to use the language 
sensibly.

In order to be able to write low-level code like IdentityHashMap in 
Java, we need to be able to express both subst== and deep==.  It may 
that 25 years ago we picked the wrong meaning to bind to ==, but that's 
how the language works already.  For dyamically typed (Object-consuming) 
and generic code, we have guided users towards the LIFE (Legacy Idiom 
for Equality) idiom: x == y || x.equals(y) /strictly because of the cost 
model of 1995, because virtual calls were expensive/.  Sad, but the 
world is full of this code, so we shouldn't break it.  But, as the cost 
model shifts, we can also guide people away from it and towards just 
doing x.equals(y) /because the cost model has changed/ (again).  Which 
we can do through recommendations, style codes, education, and static 
analysis.  But I don't disagree with your conclusion that /most of the 
time/, == comparisons are suspect (on refs and on values), and most of 
these LIFE instances should, eventually, be replaced by plain old 
`x.equals(y)`.