On 5/16/19 10:06 PM, Alan Snyder wrote:
Could you explain the inconsistency in the specification that affects
removeAll()? I don’t see it.
It's the assumption that the operation can be reversed without changing its
semantics. This isn't true, given the existence of SortedSet et. al. This is the
point of this bug report. The inconsistency exists in the collections framework
specifications taken as a whole, not removeAll() in isolation.
I believe I already accepted the fact of ersatz Collections.
Of course I don't know your state of mind, but it it doesn't sound to me like
you've accepted them. You're calling them "ersatz" collections, which sound to
me like "fake" collections. You're carving them out of "real" collections and
treating them like second-class citizens. I would have thought that was an
overstatement, until I read this:
Promoting ersatz Collections to first class citizens would be a significant
incompatible change...
My goal here is to reconcile the various parts of the collections framework
specifications so that they are more self-consistent as a whole. Treating
certain pieces as second-class citizens makes the problem worse, not better.
What I would most like to preserve is the performance advantages of using hash
coding, which apparently was a goal of the original design:
"implementations of the various Collections Framework interfaces are free to take
advantage of the specified behavior of underlying {@link Object} methods wherever the
implementor deems it appropriate"
Promoting ersatz Collections to first class citizens would be a significant
incompatible change to the specification because it invalidates this statement.
My changes don't affect the relationship of equals() and hashCode() in the
slightest.
s'marks
