On Thu, 30 Mar 2023 11:33:14 GMT, Chen Liang <li...@openjdk.org> wrote:
>> In the JEP: >>> A sequenced collection supports common operations at either end, and it >>> supports processing the elements from first to last and from last to first >>> (i.e., forward and reverse). >> >>> The reverse-ordered view enables all the different sequenced types to >>> process elements in both directions, using all the usual iteration >>> mechanisms: Enhanced for loops, explicit iterator() loops, forEach(), >>> stream(), parallelStream(), and toArray(). >> >> This implies that for the reversed view, collection operations are not only >> supported, but can potentially be optimized. Our design should anticipate >> implementations of `SequencedCollection` to provide specific reversed >> implementations, like what we are already doing with `addAll` in ArrayList >> and ArrayDeque. If a collection cannot have efficient reverse-sequenced >> operations, it shouldn't be retrofitted into `SequencedCollection`, just >> like how we don't fit Deques into Lists. >> >> Hence, I recommend: >> 1. Declare `reversed()` and one of the (First/Last) operation sets >> (add|get|remove) `abstract`, and delegae the other set to default call the >> operation on the reversed instead. >> - Since we tend to work with the end of collections, I'd declare the >> `Last` methods to be abstract and delegate the `First` default >> implementations to `this.reversed().xxxLast()` >> 2. I don't think leaving `addLast()` implemented by default is a good idea, >> for modifiable implementations cannot discover that they missed the >> `addLast()` at compile time and can only discover when the implementation is >> actually used. >> 3. In the default `reversed()` implementation of `List` and `Deque`, add API >> notes to indicate to implementations opportunities to optimize the >> implementation, especially batch operations like `addAll` when the base >> implementation offers such an optimization. > >> @liach >> >> I understand that you're suggesting adding various default implementations >> in order to make it easier for people to bring up implementations of >> SequencedCollections. However, adding default implementations to >> SequencedCollection itself is unlikely to help. I expect that most >> implementations will override both addFirst and addLast. Requiring >> overriding of only one of them will hardly help anything, because the more >> difficult task is implementing the reverse-ordered view. I'd prefer to >> concentrate on some kind of implementation assistance for doing that. For >> example, there could be an "AbstractSequencedCollection" that would require >> overriding only a couple methods, rather like `AbstractCollection`. I'm a >> bit reluctant to introduce new abstract classes into the public API though. >> An alternative might be to have some kind of static factory method that >> takes something like a Collection and a reverse iterator and returns a >> SequencedCollection. >> >> It's not clear to me that such support is necessary. It's pretty easy to >> bring up a List using AbstractList, and a List is a SequencedCollection. But >> if we do add something, it should be driven by use cases, and not >> speculation. > > Then shouldn't we leave all methods in SewuencedCollection abstract as users > almost always override them? @liach > Then shouldn't we leave all methods in SequencedCollection abstract as users > almost always override them? No. The getX and removeX default methods are built on iterators, upon which a full collection implementation can be built. See AbstractCollection. If you have a reversed iterator, you can build a reversed view from that, and you're done. In fact these default methods are used by the sequenced view collections of SequencedMap. ------------- PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1512279356
