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.
