Migrating methods in Collections

[Doug Lea]

Before commenting on details, a few preliminaries.

1. It seems unresolved in the current State of Values doc
whether value types will have user-definable equals()
methods. I think that this needs to be settled soon:

If value types don't allow overriding equals, and if the implementation
is "has same type and bits", then some of the problems you note
almost disappear. For example c.contains(x) could be automatically
translated into "false" if c is a collection of a different val type
than x, or x is a ref type or null. Which also happens to catch all
the type-problematic cases. I'm not sure how a compiler would know
to do this though.

(The complementary case where c is Collection<T> (non-any), and x is
a possibly-boxable value generalizes how Collection<Integer>
currently acts, which doesn't seem to need any change.)

2. It seems irresponsible to spend so much effort on
Collections without also somehow addressing 32bit size/index
limitations. Yes?

3. Similarly for value-like (aka fluent-immutable, aka persistent)
collection methods, possibly in sub or super interfaces, or just
extension methods in Collection. As in:
   Collection<T> adding(T x);
   Collection<T> removing(T x);

(In other words, if collections support values, users will also
expect value-like collections/APIs.)

Existing collections might just clone-then-mutate, but others
(like HAMTs that we don't support in part for lack of API) would
do something cheaper. (Default implementations seem possible, but
only via messy reflection.)

Sorry that (2) and (3) are almost out of scope of this discussion,
but merely "almost" -- they seem to interact at least a little.

-Doug