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
