[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: RFR: 8266571: Sequenced Collections [v4]
From:       Chen Liang <liach () openjdk ! org>
Date:       2023-03-30 11:36:34
Message-ID: bvC1bZAPG4HVrez7a9gCe3IoStyBOsGFM1ZAMNTJ-kE=.96af85d9-7809-4dcf-b5ce-e3dc2278d413 () github ! com
[Download RAW message or body]

On Wed, 29 Mar 2023 21:18:02 GMT, Chen Liang <liach@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


[prev in list] [next in list] [prev in thread] [next in thread]