Sequenced Collections

[Stuart Marks]

On 10/4/22 9:38 PM, Ernie Rael wrote:
> Summary of key points (maybe the mail was TL;DR)

OK thanks, I was still mulling over the previous email wondering which parts were 
significant enough to reply to.

>   * SequencedCollection methods addFirst,addLast are the only methods in
>     Collection hierarchy (AFAIK) that might modify the collection and do
>     not return/signal if the collection was modified. Seems like
>     offerFirst,offerLast are more consistent with Collections and still
>     avoid method proliferation.

The problem is that the boolean return values from add() and from offerX() mean 
different things, and having them be adjacent on List would be confusing. (Yes, 
they're both present on Deque, which is one of the reasons Deque is too 
complicated.) And we couldn't adjust the semantics of SequencedCollection.offerX() 
to match add(), as that would clash with the existing semantics on Deque.

 From your other messages it seems like you want the boolean return value in order 
to keep track of whether the collection changed such that it affects equals() and 
hashCode(). There are other methods that might modify collections where you can't 
tell whether they actually modified the collection; consider Collection::clear or 
List::replaceAll. So I don't think the boolean return value from add/offer is really 
buying you all that much.

>   * With LinkedHashSet, seems like listIterator is missing. Rather than
>     making that part of SequencedCollection, maybe an "interface
>     ListIterable { ListIterator listIterator(int index); }". In addition
>     to modification, bi-directional might also be optional, to support
>     it's use with list equals.

ListIterator has indexes and so it's pretty much tied to List. Maybe what you're 
missing from LinkedHashSet is the ability to insert or reposition an element 
somewhere in the middle? This is certainly a valid use case, but it's quite rare, 
and I'm not sure I'd want to support it using an Iterator style mechanism anyway.

Surveying the usages of ListIterator, I found that it's mainly used for iteration in 
reverse, and secondarily for replacing all the elements of a List (somewhat 
supplanted by replaceAll). We did run into one case where ListIterator was used to 
edit items within a list but it turned out to be INCREDIBLY clumsy to use. So if we 
want to support that (fairly rare) use case, I wouldn't start with a ListIterator or 
some variant with indexes removed. I'd also want to see use cases before considering 
adding new mechanisms.

s'marks