ReversibleCollection proposal

[Remi Forax]

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Jeudi 22 Avril 2021 00:14:10
> Objet: Re: ReversibleCollection proposal

> 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

I would like to preserve the invariant that, when calling a method on a Collection/iterator, an UnsupportedOperationException only occurs when trying to mutate that collection.
If we are ok with that, this means that addFirst can not be a default method of Collection.

getFirst() on Collection is a nice addition has I already said.

And i'm not a big fan of removeFirst() on Collection, mostly because i think that the sequence this.iterator + next() + remove() is pretty rare on a Collection or a Set
(i would also like to keep the invariant that Set and Collection have the same set of methods).

So addFirst/addLast/removeFirst/removeLast should be added to SortedSet/NavigableSet, Deque, List and LinkedHashMap (if there are not already present).

For reverse/descending, I still prefer to have descendingSet() on Set and descendingList() on List, the same way we have keySet() or subList() (the method names have the resulting interface has suffix).
This also solve the issue with LinkedList implementing both List and Deque.

I believe that the cost of introducing ReversibleCollection is too high
- it's not source backward compatible change
- replacing Collection/Set by ReversibleCollection/ReversibleSet has return type of an existing interface/class is not a source backward compatible change
- to be able to use ReversibleCollection parameter of a public method of a library, we have to wait the whole Java ecosystem to have been updated to implement ReversibleCollection (Python 2/3 like migration).

> 
> Stephen

Rémi