On Wed, 29 Mar 2023 21:18:02 GMT, Chen Liang <li...@openjdk.org> wrote:
>> Stuart Marks has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Simplify handling of cached keySet, values, and entrySet views. > > 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? ------------- PR Comment: https://git.openjdk.org/jdk/pull/7387#issuecomment-1490144021
