On Wed, 29 Mar 2023 21:18:04 GMT, Rémi Forax <fo...@openjdk.org> wrote:
>> In the JEP, it says: >>> Any modifications to the original collection are visible in the view. >> >> If we don't have an efficient reversed view, I don't see a point of >> declaring a collection sequenced; same reason for declaring a >> sequenced/deque vs. a full-on list with inefficient list random access >> operations. > > The quote is from the javadoc of reversed (see above), it seems the JEP and > the javadoc disagree :( > >> If we don't have an efficient reversed view, I don't see a point of >> declaring a collection sequenced > > Collections in the JDK provides more efficient implementations, this is what > the code this PR does. > Providing a default implementation matters more for external libraries. > > And that's why i think we do not need the interface SequencedCollection, > because all these methods can be declared on Collection instead. Adding them > on Collection has also the added benefit that as a user, all Clojure > collections or any other implementations not in the JDK also get a good > enough implementation of the method reversed(). > > My fear is that if we introduce all these methods on SequencedCollection > instead of Collection, library implementations will never be updated to use > SequencedCollection instead of Collection (because implementing > SequencedCollection requires the library to work only on JDK 21+) while if > reversed is declared on Collection, library maintainers will have more > pressure to write an efficient implementation of reversed for their > implementations (and will be able to do that without requiring the JDK 21). So your model would be like: public interface Collection<T> ... { ... default Collection<T> reversed() {...} // - can dump to array default void addLast() {...} // or addFirst - no reliable impl default boolean removeLast() {...} // or removeFirst - no reliable impl default T getLast() {...} // or getFirst - can dump to array } I don't think `reversed()` is the problem here; `addLast` `removeLast` cannot be implemented from the existing Collection methods without risking contract violations, so I don't recommend leaving them as default methods. I still think SequencedCollection should exist for its specification of add/removeLast and improved performance of getLast. That said, it is true that SequencedCollection as an interface itself has less merit as unmodifiable/immutable collections. It will only work as a marker indicating the contract that an encounter sequence is defined. For libraries, they can use version-specific class files in META-INF; to un-sequence a collection implementation should be quite simple, as nuking the bridge `reversed` returning `SequencedCollection` and the `SequencedCollection` symbol from interface lists. This can be done with a simple classfile transformer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/7387#discussion_r1152623381