ReversibleCollection proposal

[Stuart Marks]

On 4/16/21 3:06 PM, Donald Raab wrote:
> We should be cautious when adding new APIs to existing interfaces. There may be libraries which extend JDK types and already have reversed(), toReversed() or asReversed() APIs and corresponding interfaces.
> 
> There are OrderedIterable and ReversibleIterable interfaces and asReversed() and toReversed() methods in the Eclipse Collections API.

Hi Don, thanks for looking at the proposal.

Certainly a lot of care is required when introducing new interfaces, new methods on 
existing interfaces, and covariant overrides. I believe the primary risks are with 
name clashes and with return type mismatches.

On name clashes, "reversed" seems to thread the needle well, as I cannot find any 
methods with that exact name on Eclipse Collections, Guava, Apache Commons 
Collections, or several others. There are methods with similar names, of course, 
such as "reverse", "asReversed", and "toReversed" but they shouldn't cause name 
conflicts.

(There might be semantic conflicts, such as creating an reversed copy instead of a 
reversed view, but I don't think that can be helped.)

If there are no name clashes with "reversed", the covariant overrides in the 
sub-interfaces won't a problem. The covariant overrides on existing methods (such as 
LinkedHashMap.entrySet) are a greater danger, I think. There are a lot of 
LinkedHashMap subclasses (several dozen are visible in the Yawkat browser) but only 
one had a conflicting override. It's trivially fixable, but nonetheless it's an 
incompatibility.

I'm also concerned about conflicts over the other method names; something like 
addFirst() is a pretty obvious method to add to a custom List implementation. I 
haven't seen any, but that doesn't mean there aren't any.

s'marks