Substitutability, was Re: Finding the spirit of L-World

[Stephen Colebourne]

On Fri, 22 Feb 2019 at 21:49, Brian Goetz <brian.goetz at oracle.com> wrote:
> So == (continues to) means "are you exactly the same thing"; .equals()
> (continues to) means "are you logically the same thing", as with refs
> today.

I agree with this entirely.

To me, == and identityHashCode are about comparing the raw bits in
memory (even if that is not 100% true, it is a reasonable mental model
and an easy way to sell the concept). Raw bits can easily be used to
explain references, nulls, primitives and floating point issues like
NaN. BTW, the idea of returning false or throwing from == fills me
with horror.

I've said it before, but references are a kind of value too - a
pointer. Pushing the "references are values too" mental model over the
next few years would be very helpful to getting developers to
understand how additional value types interact with references.

More radically, I think a lot of the debate here is due to the syntax
pain, which would go away if an additional operator was added to Java:

 a == b    // as today
 a .= b    // compiled to Objects.equal(a, b) or similar
etc
(The new operator would be a compiler fiction, not a JVM bytecode,
except that .= would work for primitives too)

Who would use == on a Class or Enum when .= is just as short and
consistent with every other comparison in their code? ie. we have this
problem because the language makes it hard to do the "right thing".
While obviously the syntax is not super attractive it is the product
of Java's history, and I still think it would make Java code
dramatically more readable and enjoyable to write. My preference would
also be to deprecate == and push users to a method on System but
that's a separate decision.

On Sat, 23 Feb 2019 at 04:24, John Rose <john.r.rose at oracle.com> wrote:
> The obvious reason to make System.substitutabilityHashCode
> be a different API point from System.identityHashCode is that
> that latter mentions "identity".  So there's a clear pedagogical
> problem here, if we are telling students "value = object - identity".

As above, maybe "value = object - identity" isn't the right model to
sell. Maybe "everything is a value, objects are at the end of a
pointer value" is a better model.Then in terminology, maybe you can
extend the meaning of "identity" to be "the raw bits in memory"?  (I
get that such a terminology tweak would be hard for JVM authors, but I
think it might be just fine for the mainstream development world). It
would help in explaining System.identityHashCode(). Thus it would be
isSameIdentity(a, b).

Stephen