Value equality

[John Rose]

On May 17, 2016, at 12:20 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> Hi,
> 
> I think that, to avoid confusion, there should be no special treatment of arrays. They should be treated as any other reference. Why?
> 
> Reason #1:

To me, your reason #1 boils down to saying that special treatment of arrays requires a surprising break to a certain property of reference subtyping, that an operation a.m(b) means the same thing regardless of the static type of a.

And I concur.  That's a valuable property.  Generally, static subtypes add new methods (already latent under the supertype) but do not change methods.

> Reason #2:
> 
> It's not difficult to create a standard reusable value type wrapping a single array with suitable equals() override:

Yes.  There is a choice of simple workarounds:  override equals or use a ref-to-val semantic wrapper.

As I implied in my earlier note, there are many candidates for equivalence relations.  But the basic system hangs together best if we make use of as few of them as possible, by default at least, and allow users to import other equivalences, ad hoc, using either overrides or wrappers.

> ...  and use it instead of plain array(s) as components of other value or reference types, with no runtime overhead compared to plain arrays. For this to work then default .equals() for value types should:
> 
> - compare primitive components with ==(p, p) (modulo float/double variations for which I don't have an opinion yet)
> - compare reference components with .equals()
> - compare value components with .equals() - yes, this gives the most intuitive result and encapsulates equality into the classes of the components.

This is where things get interesting!  The .equals method has to tie everything together nicely.

> For == operator on value types then I don't know. Perhaps it should be the "bit-wise" comparison of components or, a John would say, copy-equivalence.
> 
> That's simple to grasp and explain and is also usable.

I'd like to rework an earlier message on the Big Picture of equality semantics (with steps 0..3), after discussing it locally with some colleagues.  I'll do that in a followup.

— John