[External] : Sequenced Collections

Stuart Marks stuart.marks at oracle.com
Tue Feb 15 06:45:01 UTC 2022



On 2/11/22 7:24 PM, Tagir Valeev wrote:
> Of course, I strongly support this initiative and am happy that my proposal got some 
> love and is moving forward. In general, I like the JEP in the way it is. I have only 
> two slight concerns:

> 1. I'm not sure that having addition methods (addFirst, addLast, putFirst, putLast) 
> is a good idea, as not every mutable implementation may support them. While this 
> adds some API unification, it's quite a rare case when this could be necessary. I 
> think most real world applications of Sequenced* types would be around querying, or 
> maybe draining (so removal operations are ok). Probably it would be enough to add 
> addFirst, addLast, putFirst, putLast directly to the compatible 
> implementations/subinterfaces like List, LinkedHashSet, and LinkedHashMap removing 
> them from the Sequenced* interfaces. In this case, SortedSet interface will not be 
> polluted with operations that can never be implemented. Well my opinion is not very 
> strong here.

Hi Tagir, thanks for looking at this.

Yes, this particular issue involves some tradeoffs. As you noted, addFirst/addLast 
can't be implemented by SortedSet and so they throw UOE. This is an unfortunate 
asymmetry. If these were omitted, the design would be cleaner in the sense that 
there would be fewer things that throw UOE.

But there are costs to not having those methods, which I think outweigh the 
asymmetry around SortedSet.

The other collections have interfaces corresponding to common implementations: 
ArrayList has List, ArrayDeque has Deque, TreeSet has SortedSet, etc., and Java 
style tends to encourage "programming to the interface." But there's no interface 
that corresponds to LinkedHashSet.

Over the years we've mostly just put up with this gap. But it's really noticeable 
when you add the reversed view. The reversed view of a List is a List, the reversed 
view of a Deque is a Deque, the reversed view of a SortedSet is a SortedSet, and the 
reversed view of a LinkedHashSet is a ... what? SequencedSet is the answer here.

We also want the reversed view to be equivalent in power to the forward view. If the 
addFirst/addLast methods were only on LinkedHashSet, it would be possible to add at 
either end of a LinkedHashSet but not its reversed view. This is a big hole. So the 
addFirst/addLast methods need to be on the interface. Since the method 
specifications originally came from Deque, they're actually on SequencedCollection.

In addition, the majority of cases can implement addFirst/addLast: Deque, List, 
LinkedHashSet. SortedSet is the outlier; it would seem a shame to omit the methods 
only because of SortedSet. The alternative is to omit SortedSet from the 
SequencedCollection family, but that seems worse, as SortedSet can implement the 
other operations just fine.

> 2. SequencedCollection name is a little bit too long. I think every extra letter 
> adds a hesitation for users to use the type, especially in APIs where it could be 
> the most useful. I see the Naming section and must admit that I don't have better 
> ideas. Well, maybe just Sequenced would work? Or too vague?

Yeah, the names are rather longer than I would have liked. At least "Sequenced" is 
shorter than "Reversible". :-)

One reason it's ok to have a longer name is that it reduces the possibility of name 
collections.

We want the types to be nouns, so the obvious noun here is Sequence. But we need Set 
and Map variations as well, so that would result in

     Sequence
     SequencedSet
     SequencedMap

or similar variations. Kind of asymmetrical. Or maybe Seq, SeqSet, SeqMap? Not 
clearly better.

One nice thing about the names in the current draft is that they line up with the 
existing collection types nicely:

     Collection    SequencedCollection
     Set           SequencedSet
     Map           SequencedMap

I'm not claiming these are absolutely the best names, but I've thought about this 
for a while and I haven't been able to come up with anything clearly better. I'm 
open to better names if there's something I might have missed though.

s'marks


More information about the core-libs-dev mailing list