ReversibleCollection proposal

[Donald Raab]

Hi, Stuart, happy to help.

I took a look at Groovy and Kotlin. Groovy has reverse() [1] and Kotlin has reversed() [2] and asReversed() [3] and reverse() [4]. I’m not quite familiar enough with Kotlin to know whether the reversed() method will collide.

[1] http://docs.groovy-lang.org/latest/html/groovy-jdk/java/util/List.html#reverse()
[2] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/reversed.html
[3] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/as-reversed.html
[4] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/reverse.html

> On Apr 17, 2021, at 2:24 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> 
> 
> 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