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.ma...@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
