Equality

[Brian Goetz]

> Where I think this page says that interfaces with existing methods
> accepting Object args can in principle be anyfied without strictly
> requiring (but usually strongly encouraging) implementation class rework.

I want to draw a strict distinction between "migrating APIs" and 
"migrating implementations."  The messages so far have been deliberately 
restricted to migrating APIs, the linguistic tools available for doing 
so, and their impact on the Collection APIs.

> There is a way to enable/translate analogs of Object methods,
> in particular equals().

I was hoping to treat the Object methods in a separate discussion.  It 
does connect to this discussion in that contains() will inevitably 
appeal to equals(), but it also pulls in a zillion other things (are 
values objects?  can value implement interfaces?  is there a base type 
for values?  what is the relationship between the base type for values 
and for objects?  is there a top type?  etc.)

I think the upshot here is that the problem of "what is the signature of 
equals" is essentially the same as for contains/remove (contains 
inevitably calls equals), so we should be mindful that whatever 
discussions we have for collections are also going to impact equals, and 
ideally the same hammer pounds down both nails.

> We wouldn't normally recommend blanket anyfication of interfaces,
> but Collections is the main one that everyone hopes will be somehow
> doable.

Collections is important both because its fundamental, and because its 
the canary -- if we can't anyfy Collections, there's a good chance that 
are tools are still insufficient for migrating other real-world libraries.

> The full story on this has a few more quirks though.

This is what I was getting at above, with "let's treat the 
implementation part of the problem separately."  There are a pile of 
idioms that show up in this kind of code whose semantics gets fuzzy when 
a type variable straddles references and values -- comparison to null, 
comparison to other objects (particularly 'this', which shows up in 
AbstractList.toString), synchronization, assignment to null, 
instanceof/cast, array creation.)

My initial porting exercise of Collections leads me to conclude that the 
tools needed for migrating the APIs and the tools needed for migrating 
the code are mostly decoupled.  Since the API changes are more visible, 
I thought it sensible to start there.

 > It gets uncomfortable to cope with synchronized(obj),
 > Object.wait, and Object.notify: Semantically, synchronized(val)
 > and notify would be no-ops, and wait would block forever.

This is one approach (the "permanently locked" object approach that John 
described in an earlier Value Objects proposal), but there are others. 
Let's come back to this.