ReversibleCollection proposal

[Stephen Colebourne]

On Wed, 21 Apr 2021 at 18:39, Stuart Marks <stuart.marks at oracle.com> wrote:
> The value being provided here is that the ReversibleCollection interface provides a
> context within which specs no longer need to hedge about "if the collection has an
> ordering". APIs that produce or consume ReversibleCollection no longer need to
> include this hedge, or have disclaimers about ordering. Potential new
> ReversibleCollection implementations also need not worry about this issue in the
> same way they did when they were forced to implement Collection directly.

Having thought about this for a few days my "interesting thought" is
that adding a `ReversibleCollection` interface and adding additional
methods can be orthogonal choices.

Specifically, I do rather like Peter's suggestion of adding more
methods to Collection. Adding these methods would be pretty useful in
general and give the proposed change much greater reach:

public interface Collection<E> .... {
         default void addFirst(E e) { throw new
UnsupportedOperationException(); }
         default E getFirst() { return iterator().next(); }
         default E removeFirst() { var i = iterator(); i.next();
i.remove(); }
}

My view being that every collection has some notion of "first", even
if that notion is "undefined". If that was the only change made, I
think that would be a good move forward.

These would be the various options:

- 7 new methods on ReversibleCollection (Stuart's suggestion)
- 7 new methods on Collection, no ReversibleCollection (Peter's suggestion)
- 3 new methods on Collection, no ReversibleCollection (my suggestion #1)
- 3 new methods on Collection, 4 methods on ReversibleCollection (my
suggestion #2)
- 7 new methods on Collection, 0 methods on ReversibleCollection (my
suggestion #3)

FWIW, I think I prefer my suggestion #2

Stephen