[External] : Sequenced Collections

[Glavo]

On the one hand, I am very opposed to using the name ` SequencedCollection
`. In the JVM ecosystem, several widely used libraries are using the term
Seq,
Typical examples are Scala and kotlin's standard libraries, Scala uses
`Seq` as a similar correspondence to a `List`, while Kotlin's `Sequence`
represents something with semantics between `Iterable` and `Stream`.
Introducing things with similar names may lead to more confusion.

On the other hand, we have defined the meaning of "ordered".
Refer to `Stream::forEachOrdered` and `Spliterator.ORDERED`. Their
semantics for known collections are similar to the one you discussed.
Direct reuse is not only shorter, but also more harmonious and unified in
semantics.
So I think `OrderedCollection` is a good choice.


On Tue, Feb 15, 2022 at 2:45 PM Stuart Marks <stuart.marks at oracle.com>
wrote:

>
>
> 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
>