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
