On Wed, 29 Mar 2023 21:18:04 GMT, Rémi Forax <[email protected]> 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
