[External] : Sequenced Collections

[Brian Goetz]

It's a time-honored tradition in naming bikesheds to pick and choose the 
precedents you want to be "consistent" with, and I think that's what's 
going on here with your preference for "Ordered" over "Sequenced".  But 
in an ecosystem as large as Java, you can always find conflicting 
precedents to be "consistent" with, which makes "for consistency" 
arguments generally weak.

There's a reason that we didn't propose "ordered", and it's not because 
it didn't occur to us; it is already heavily used to indicate ordering 
of the elements.  Any mention of Comparator or Comparable will quickly 
use the word "order" to mean ordering of the elements (after the 
mathematical terms "partial order" and "total order".)  From Comparator 
(first lines):

  * A comparison function, which imposes a <i>total ordering</i> on
  * some collection of objects.  This ordering is referred to as the 
class's <i>natural
  * ordering</i>

 From Comparable (first lines):

  * Compares this object with the specified object for order.

 From TreeSet:

  * Constructs a new, empty tree set, sorted according to the
  * natural ordering of its elements.

 From Collections::sort:

  * Sorts the specified list into ascending order, according to the
  * {@linkplain Comparable natural ordering} of its elements.

And there are also helper methods like Collections::reverseOrder and 
Comparator::naturalOrder.


So, we can find precedent for "ordered" meaning element order, and also 
for it meaning has-an-encounter-order.  So how do we choose?  Well, 
we're talking about enhancing *collections*, and throughout Collections, 
"ordered" primarily means "element order".  So while you could be mad at 
Streams for having used "ordered" to mean "has an encounter order", it's 
still not the case that both terms have an equal claim; context matters.







On 2/15/2022 2:38 AM, Glavo wrote:
> 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
>>