Re: [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.ma...@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